一、前言：
苹果官方推荐的 App 开发模式是 MVC，随之衍生出其他很多类 MVC 的设计模式 MVP、MVVM、MVCS ，它们在不同程度上增强了视图、数据的通信方式，使得逻辑、视图、数据之间的通信更灵活、规整、易于扩展。在 App 浪潮初期，几乎所有 App 采用的都是这种类 MVC 的结构。原因在于，MVC 是很好的面向对象编程范式，非常适合个人开发或者小团队开发。但是，项目大了，人员多了以后，这种架构就扛不住了。因为，这时候功能的量级不一样了。一个大功能，会由多个功能合并而成，每个功能都成了一个独立的业务，团队成员也会按照业务分成不同的团队。此时，简单的逻辑、视图、数据划分再也无法满足 App 大规模工程化的需求.
二、大项目、多人、多团队架构思考接下来，我先和你说下模块粒度应该怎么划分的问题。
首先，项目规模变大后，模块划分必须遵循一定的原则。对于 iOS 这种面向对象编程的开发模式来说，我们应该遵循以下五个原则，即 SOLID 原则。
单一功能原则：对象功能要单一，不要在一个对象里添加很多功能。
开闭原则：扩展是开放的，修改是封闭的。
里氏替换原则：子类对象是可以替代基类对象的。
接口隔离原则：接口的用途要单一，不要在一个接口上根据不同入参实现多个功能。
依赖反转原则：方法应该依赖抽象，不要依赖实例。
iOS 开发就是高层业务方法依赖于协议。同时，遵守这五个原则是开发出容易维护和扩展的架构的基础。最后，我们需要选择合适的粒度。切记，大型项目的模块粒度过大或者过小都不合适。其中，组件可以认为是可组装的、独立的业务单元，具有高内聚，低耦合的特性，是一种比较适中的粒度。就像用乐高拼房子一样，每个对象就是一块小积木。一个组件就是由一块一块的小积木组成的有单一功能的组合，比如门、柱子、烟囱。在我看来，iOS 开发中的组件，不是 UI 的控件，也不是 ViewController 这种大 UI 和功能的集合。因为，UI 控件的粒度太小，而页面的粒度又太大。iOS 组件，应该是包含 UI 控件、相关多个小功能的合集，是一种粒度适中的模块。
三、我心目中好的架构是什么样的？
组件化是解决项目大、人员多的一种很好的手段，这在任何公司或团队都是没有歧义的。组件间关系协调却没有固定的标准，协调的优劣，成为了衡量架构优劣的一个基本标准。所以在实践中，一般分为了协议式和中间者两种架构设计方案。
协议式架构设计主要采用的是协议式编程的思路：在编译层面使用协议定义规范，实现可在不同地方，从而达到分布管理和维护组件的目的。这种方式也遵循了依赖反转原则，是一种很好的面向对象编程的实践。但是，这个方案的缺点也很明显，主要体现在以下两个方面：由于协议式编程缺少统一调度层，导致难于集中管理，特别是项目规模变大、团队变多的情况下，架构管控就会显得越来越重要。协议式编程接口定义模式过于规范，从而使得架构的灵活性不够高。当需要引入一个新的设计模式来开发时，我们就会发现很难融入到当前架构中，缺乏架构的统一性。虽然协议式架构有这两方面的局限性，但由于其简单易用的特点依然被很多公司采用,代表有BeeHive，https://github.com/alibaba/BeeHive
另一种常用的架构形式是中间者架构。它采用中间者统一管理的方式，来控制 App 的整个生命周期中组件间的调用关系。同时，iOS 对于组件接口的设计也需要保持一致性，方便中间者统一调用，代表有：CTMediator，https://github.com/casatwy/CTMediator
附上组件分层图：
调用链自上而下，上层组件通过组件中心进行解耦通讯（业务组件、功能组件），底层组件通过直接#import的方式调用（UI组件、基础组件、工具/扩展）
