有太多的文章教你怎么组织代码了。但是这些文章大都是系统A，模块B的抽象写意派。虽然看着很有道理的样子，但就是看不懂。 本文的特点是有十多个带有具体业务场景的例子。从如何接新需求的角度来分析模块应该怎么拆分。 主要的内容都在例子里，请不要直接看结论，相信我，只看结论等于没看。
- 模块化的三个目的
- Autonomy: 减少沟通成本，一个需求改的模块数尽可能的少，一个模块的负责团队需要的知识边界尽可能的小。
- Consistency: 在保障 Autonomy 的情况下，通过模块复用，减少不必要的不一致性。
- Feedback: 降低获得反馈的成本，让新人能够快速上手。最有效的“文档”是可工作的软件本身提供的交互式学习环境。拆成模块之后可能就不需要整体跑起来也可以获得反馈。
- Patterns