应用程序结构如果一个对象应该在许多子域应用程序中
我想构建游戏管理。用户可以玩很多游戏，每个游戏都有自己的分数，等级，用户的徽章。因此，让我得出这样的应用程序的基本结构：应用程序结构如果一个对象应该在许多子域应用程序中
Game-Management
Game-1
User: (internal logic of gameplay: how user move, how user buy item, how get user's score...)
Game-2
User: (other logic: how user add new user to friend list, how user get to battle, ...)
...
Game-N
后端是非常好的，因为每场比赛由一个团队开发，这些团队不需要知道对方。 但在前端，我想管理所有用户游戏的统计数据。用户转到他的个人资料页面，此页面列出他所玩的所有游戏。当他点击一个游戏时，所有的统计数据都会显示出来。例如，他点击到Game-1，他可以查看他的分数，他购买的所有物品。如果他点击Game-2，他可以查看他的朋友列表，他加入了多少次战斗。
但是这是关键点，因为在后端，我的团队分别开发每个游戏，而在前端我只想在一个地方管理它们。所以这个想法好还是不好？如果它很好，我如何在后端和前端构建我的应用程序？否则，请给我其他解决方案。谢谢！
我想我会建议你使用基于空间的架构。
它被谷歌和雅虎等巨大公司广泛用于构建易于集成的不同类型的模块。
http://en.wikipedia.org/wiki/Space-based_architecture
所以基本上你有经理的对象，这将操纵模型。
模型上的函数将只接收一种模型的一种类型的消息对象。
模型上的函数还会返回一种模型的一种类型的消息对象。
所以，你有GameManager对象作为处理网格层。
然后，你有Game1Message对象作为消息网格层。
接下来，您将DbModel: a.k.a User对象作为数据网格图层。
谢谢
这是一个很好的点，我遇到这个问题了几次过去。在服务器本地
- 商店统计/日志和从中央服务器收集此：
我在两种不同的方式解决了这个。 临：
- 易于控制负载
- 有
- 你获得本地服务器上的一些备份空间
- 每场比赛能更统计/数据添加到日志它更容易无单一故障点添加这种类型的数据
- 本地磁盘写入是一个非常快速的动作，比RestApi更快。这里没有网络层。
- 您可以在中央服务器上控制工作负荷
缺点：
- 格式应该由所有不同的服务器
- 向上扩展来满足，如果一个游戏是超级流行的CAN有点问题
- 您需要确保写入日志的文件全部同步
- 与中央服务器可以收集在高容量磁盘放在高负荷的工作在一台服务器
- 上总会有一个最大容量（〜600 I/O的SaaS，5000 I/O SSD）
2.RestAPI在一台可处理所有数据的中央服务器上，每场比赛都会通过API报告需要进行统计跟踪的事件。您还可以使用第三方的事件记录（谷歌分析事件），并通过API
赞成这个报告拉：
- 简单集成的开发
- 轻松地添加新的功能
- 规模与应用程序更容易。该API可以直接给负载均衡，将引导到处理负载
缺点很多
服务器：
- 网络负载现在被添加到服务器的负载
- 依靠网络延迟/停机
- 依靠游戏上的另一台服务器的负载
实施使用API非常简单，本地日志可能有点棘手。您需要分发日志格式。为日志创建一个已知文件夹，并为主服务器创建一个映射，以了解从何处收集数据，然后将其解析为数据库。尽管听起来更复杂，但我发现第一种方法非常有效，并且帮助我降低了服务器成本。
希望有这个帮助..