注：【本文内容是阅读「戴铭」老师的iOS开发高手课内容后，自己的笔记总结】

1、开发架构基本模式演变历程

苹果官方推荐的 App 开发模式是 MVC，随之衍生出其他很多类 MVC 的设计模式 MVP、MVVM、MVCS ，它们在不同程度上增强了视图、数据的通信方式，使得逻辑、视图、数据之间的通信更灵活、规整、易于扩展。在 App 浪潮初期，几乎所有 App 采用的都是这种类 MVC 的结构。原因在于，MVC 是很好的面向对象编程范式，非常适合个人开发或者小团队开发。

但是，项目大了，人员多了以后，这种架构就扛不住了。接下来我们就不得不考虑模块粒度如何划分、如何分层，以及多团队如何协作这三个问题了。

首先，项目规模变大后，模块划分必须遵循一定的原则。如果模块划分规则不规范、不清晰，就会导致代码耦合严重的问题，并加大架构重构的难度

其次，我们需要搞清楚模块的粒度采用什么标准进行划分，也就是要遵循的原则是什么。对于 iOS 这种面向对象编程的开发模式来说，我们应该遵循以下五个原则，

2、即 SOLID 原则。

1>单一功能原则：对象功能要单一，不要在一个对象里添加很多功能。

2>开闭原则：扩展是开放的，修改是封闭的。

3>里氏替换原则：子类对象是可以替代基类对象的。

4>接口隔离原则：接口的用途要单一，不要在一个接口上根据不同入参实现多个功能。

5>依赖反转原则：方法应该依赖抽象，不要依赖实例。iOS 开发就是高层业务方法依赖于协议。

最后，我们需要选择合适的粒度。切记，大型项目的模块粒度过大或者过小都不合适。

iOS 开发中的组件，不是 UI 的控件，也不是 ViewController 这种大 UI 和功能的集合。因为，UI 控件的粒度太小，而页面的粒度又太大。iOS 组件，应该是包含 UI 控件、相关多个小功能的合集，是一种粒度适中的模块。

3、功能模块之间的耦合解除，就需要重新梳理组件之间的逻辑关系，进行改造。

但是，组件解耦并不是说要求每个组件间都没有耦合，组件间也需要有上下层依赖的关系。组件间的上下层关系划分清楚了，就会容易维护和管理。而对于组件间如何分层这个问题，层级最多不要超过三个。

你可以这么设置： 

1> 底层可以是与业务无关的基础组件，比如 网络、存储、通用弹框、加密、字符处理、数组扩展、字典扩展等等；

2>中间层一般是通用的业务组件，比如 账号、埋点、支付、购物车等项目中公共业务等；

3>最上层是 「迭代业务」组件，更新频率最高。

这样的三层结构，尤其有利于多个团队分别开发维护。比如，一开始有两个业务团队 A 和 B，他们在开发时既有通用的功能、账号、埋点、个人页等，也有专有的业务功能模块，每个功能都是一个组件。也不用把所有的功能都做成组件，只有那些会「 被多个业务或者团队」使用的功能模块才需要做成组件。

4、组件化是解决项目大、人员多的一种很好的手段，这在任何公司或团队都是没有歧义的。组件间关系协调却没有固定的标准，协调的优劣，成为了衡量架构优劣的一个基本标准。所以在实践中，一般分为了「协议式」和「中间者」 两种架构设计方案。

「协议式架构」设计主要采用的是协议式编程的思路：在编译层面使用协议定义规范，实现可在不同地方，从而达到分布管理和维护组件的目的。这种方式也遵循了依赖反转原则，是一种很好的面向对象编程的实践。

但是，这个方案的缺点也很明显，主要体现在以下两个方面：

1>由于协议式编程 缺少统一调度层，导致难于集中管理，特别是项目规模变大、团队变多的情况下，架构管控就会显得越来越重要。

2>协议式编程接口定义模式过于规范，从而使得架构的灵活性不够高。当需要引入一个新的设计模式来开发时，我们就会发现很难融入到当前架构中，缺乏架构的统一性。

虽然协议式架构有这两方面的局限性，但由于其简单易用的特点依然被很多公司采用。

另一种常用的架构形式是「中间者架构」。它采用  中间者统一管理的方式，来控制 App 的整个生命周期中组件间的调用关系。同时，iOS 对于组件接口的设计也需要保持一致性，方便中间者统一调用。拆分的组件都会依赖于中间者，但是组间之间就不存在相互依赖的关系了。

中间者架构的易管控带来的架构更稳固，易扩展带来的灵活性，所以我认为中间者这种架构设计模式是非常值得推荐的。casatwy 以前设计了一个 CTMediator 就是按照中间者架构思路设计的。你可以在GitHub上看到它的内容。