04-项目大了人员多了，架构怎么设计更合理

总体来说，架构是需要一步步演进的，如果项目规模大了还不演进，必然会拖累业务的发展速度。从简单架构往大型项目架构演进中，需要解决三个问题：
1.模块粒度如何划分
2.如何分层
3.多团队如何协作

模块粒度如何划分

模块粒度划分是一个细活，最好可以在不同阶段采用不同的粒度划分模块。模块划分时需要遵循五个原则，即SOLID原则：

• 单一功能原则：对象功能要单一，不要在一个对象里添加很多功能；
• 开闭原则：对扩展开放，对修改封闭；
• 里氏替换原则：子类对象可以替代基类对象；
• 接口隔离原则：接口用途要单一，一个类对另一个类的依赖性应建立在最小接口上；
• 依赖反转原则：方法应该依赖抽象，不要依赖实例。iOS开发就是高层业务方法依赖于协议；
  模块可以认为是独立的业务单元，具有高内聚、低耦合的特性，例如登陆模块、分享模块、定位模块、支付模块等。我们可以先按照物理划分，将同一功能模块的类移动到同一文件夹下，做成cocoapods包进行管理。

如何分层

戴铭老师的建议是最多不要超过三层，可以这么设置：

• 底层是与业务无关的基础组件，比如网络和存储等；
• 中间层是通用的业务组件，比如账号、埋点、支付等；
• 最上层是迭代的业务组件，更新频率最高；

多团队之间如何分工

一个合理的团队结构应该是这样的：

• 首先，需要一个专门的基建团队，负责业务无关的基础功能组件和通用业务组件的开发；
• 然后，每个业务都有一个专门的团队负责开发。业务可以按照功能耦合度来划分，耦合度高的业务划分成一个单独的业务团队，比如机票业务单独一个团队，酒店业务单独一个团队；
• 基建团队人员应该是流动轮岗的，从业务团队里来，再回到业务团队里去。
  总结来说，团队分工还是要灵活，不能太隔离固化了，团队分工还是要围绕具体的业务进行功能模块提炼，提炼的通用模块下沉，然后做精做扎实。

好的架构是什么样的

在实践中，一般分为了协议式和中间者两种架构设计方案（Router的方式缺点比较明显）。
协议式架构主要采用协议式编程的思路：在编译层面使用协议定义规范，实现可在不同地方，从而达到分布管理和维护组件的目的。但缺点也很明显，主要体现在：
1.缺少统一调度，导致难以集中管理。
2.接口定义模式过于规范，导致灵活度不够高。
中间者架构主要采用中间者统一管理的方式，来控制App的整个生命周期中组件间的调用关系。同时组件接口设计也需要保持一致性，方便中间者统一调用。个人感觉中间者架构更好一些。

中间者架构参考：https://github.com/casatwy/CTMediator；
戴铭老师在此基础上做了一些优化：https://github.com/ming1016/ArchitectureDemo