模块/组件是软件的部署单元，是整个软件系统在部署过程中可以独立部署的最小实体。 —— 《架构整洁之道》
组件聚合三原则
在我们设计软件工程的时候，我们
Bob 大叔在书中提到了三个原则：
- 复用/发布等同原则（REP）。软件复用的最小粒度等同于其发布的最小粒度。
- 共同闭包原则（CCP）。我们应该将那些会同时修改，并且为相同目的而修改的类放到同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的那些类放到不同组件中。
- 共同复用原则（CRP）。不要强迫一个组件的用户依赖他们不需要的东西。
不过，其实按我的理解，第一条原则讲的是合理、有效的包发布策略；而后两条原则，只需要满足我们的模块/包满足开闭原则、单一职责，就可以合理地解决整个流程了。不过，这三个原则可以合理地解释在软件生命周期中，我们应该如何管理模块。
因此，对于自家的模块只需要：根据技术、业务划分包，形成上下文边界，防止代码越界 。
打破包之间的依赖关系
这一步理论上来看，倒也是蛮简单的：
- 从 Gradle / Maven 找到想去除的依赖
- 全局搜索依赖的包名
- 解决依赖
- 提取到类库中
- 剥离并使用依赖注入
- 删除依赖的包
- 执行构建和 E2E 测试
TBC。工具还在写，目前主要要看人眼识别。
依赖倒置
为此，我们可能需要寻找一些合适的依赖注入框架：
- Java。Spring，Dagger 2，Guice 等等
- Go。Facebook Inject、Uber Dig、Google Wire 等
对了，静态语言呢？
- 不需要。
更好的面向对象
事实上，如果我们把面向对象做好的话，那么对应的逻辑就会封装到相应的对象中。
清理垃圾代码
未使用的类，未使用方法。它根本不知道什么时候会使用到，又或者是它已经通过多态来实现。
下一节：架构元模型定义了模型中使用的概念和使用规则。 —— 《架构师修炼之道》