参看

HellMapManager项目就是按这个架构来组织的。

对于Mud机器人，我觉得这个组织形式也适用。当然，由于主要业务不同，住址形式也会不同。我只是将所有的代码根据对应的层次打个标签，避免不同层级的代码过于混淆。

• UI 交互层 这个完全绑定于客户端的实现，在Mud机器人里也相对不重要，可以和Service层混在一起
• Service 服务器层。从字面意义上来说，就是为最终用户提供的功能的封装层。UI交互的内容最终绑定到服务层上。最大的用途是防止用户UI直接操作到业务层，做封装和拦截，以及抽象。
• Core 核心(业务) 层。对于Mud机器人来说，绝大部分的代码都是核心层。所以实际写机器人的时候Core肯定还要做细分，比如底层核心和任务模块。
• Helper 辅助类，业务层和数据层直接的纽带，将数据的细节对业务做一定的封闭。
• Adapters 适配器层 抽象底层交互。对于Mud机器人来说，就是将客户端的触发/别名/计时器做一个抽象，以及对应的事件Event框架。引入这个层的话能提升机器人可迁移性和做测试的可能。
• Model 模型 在各个业务层中共同的数据结构。在Mud中比如房间，玩家，道具等等。
• utils 工具层。比如中文转数字，格式化文字等纯与业务无关的，全局都可能使用的代码