这主要是一年多来，个人从事Erlang游戏服开发中对一些事情的思考。
想到哪说到哪，没有条理可言。
欢迎讨论。
通常Erlang游戏服务的设计涉及到的东东包括如下：
- 任务系统
- 活动系统
- 公会系统
- 玩法系统
- 好友系统
- 聊天系统
- 商城
- 转盘
- 以及其他
我经历过的项目不多，只有2个。在这2个项目中我看到系统建模都采用如下一锅端的方式：
- 即玩家进程加载了所有玩家数据，处理所有可能的系统；
- 整个游戏服通常只有玩家进程、公会进程、玩法进程以及一些公共进程。
- 整个游戏服里你看到的都是进程，看不到应用。
- 通常玩法进程很少，很多逻辑上有区别的玩法都简单粗暴塞进一个玩法进程
我很好奇，Erlang游戏服都这么做吗？在我看来，这一切都是乱糟糟的，不是说Erlang/OTP系统是以应用作为构建块的吗？
为什么我看不到任务应用，活动应用，公会应用、玩法应用、好友应用等等？以应用去划分系统不是更加清晰？也许还能按需加载
数据，而不是加载整个玩家数据呢？以应用建模，兴许能够更加容易复用代码呢？
再者所有东西糅杂在一起，系统的测试基本变得不可能；没有测试也就意味着bug.
尤其常见的是玩法进程夹杂了多种玩法逻辑，通过case if pattern match 去调用不同的代码。
通常搞好了一种玩法，也不经意导致其他玩法出现bug。（我在2个项目中都碰到了这个问题）。
我希望的游戏服设计应该是这样的：
- 系统以应用做为构建块，你会有任务应用、好友应用、商城应用、公会应用等等
- 以应用划分，玩家进程无需加载所有数据，需要的数据在相关的应用解决，甚至于对非热点数据，相关应用可能加载处理完就释放内存了。
- 以应用做划分，系统升级可以以应用为单位，热更更方便。虽然通常数据结构升级都是重启解决的，但如果能在线热更就更好了。
- 应用可单独测试，无需依赖其他东东。
- 不同的玩法以不同的进程构建，一种玩法搞好了，你无需再去理它。
也许以应用去建模，为任务构建进程显得过于大材小用。甚至于说在玩家进程里处理数据更加方便，避免不必要的进程间通信消耗。
那么我想建模成库应用也是有好处的吧。