模块粒度的划分
- 单一功能原则：对象功能要单一，不要在一个对象里添加很多功能。
- 开闭原则：扩展是开放的，修改是封闭的。
- 里氏替换原则：子类对象是可以替代基类对象的。
- 接口隔离原则：接口的用途要单一，不要在一个接口上根据不同入参实现多个功能。
- 依赖反转原则：方法应该依赖抽象，不要依赖实例。
iOS 组件应该是包含 UI 控件，相关多个功能的合集，是一种粒度适中的模块。
组件之间的逻辑关系
组件解耦并不是说要求每个组件间没有耦合，组件间也需要有上下层依赖关系。
组件之间的分层做多不超过三个：
- 底层可以是与业务无关的基础组件，比如网络和存储等。
- 中间层一般是通用的业务组件，比如账号，埋点，支付，购物车等。
- 最上层是迭代业务组件，更新频率最高。
多团队之间如何分工
- 首先，需要一个专门的基建团队，负责业务无关的基础功能组件和业务相关通用业务组件的开发。
- 然后，每个业务都由一个专门的团队负责开发。业务可以按照功能耦合度来划分，耦合度高的业务可以划分成单独的业务团队。
- 基建团队人员应该是流动的，从业务团队里来，再回业务团队中去。
中间者架构
采用一个中间者的角色来管理整个 App 的生命周期及内部的组件之间的调用关系。拆分出来的组件都依赖中间者组件，同时组件之间不存在依赖关系。由于组件之间都是通过中间者进行通信，这样更有利于管理组件之间的通信。
类似的案例有：CTMediator通过运行时，来实现了解耦。
同时 CTMediator 存在一些缺陷：
- 通过硬编码传递参数，造成便携的效率不高
- 只有运行时，才能确定调用的方法，缺少了类型检查
后来作者通过对每个组件增加一个扩展的pod解决了上述问题，即：一个业务包含了两个 Pod，一个是业务的Pod，另一个是该业务中对 CTMediator 的扩展。通过这样的扩展，使用者可以不直接使用 CTMediator 的原生方法，转而使用扩展中的方法，这样就实现了硬编码和类型检查的问题。
解耦的精髓在于业务逻辑能够独立出来，并不是形式上的解除编译