4、项目大了人员多了，架构怎么设计更合理？

苹果官方推荐的App开发模式是MVC，随之衍生很多MVC的设计模式MVP，MVVM，MVCS。
MVC是很好的面向对象编程范式，非常适合个人开发或者小团队开发。

简单架构向大型项目架构演进中，就需要解决三个问题。

即：模块粒度应该如何划分？如何分层？多团队如何协作？而在这其中，模块粒度的划分是架构设计中非常关键的一步。同时，这也是一个细活，我们最好可以在不同阶段采用不同的粒度划分模块。

对于 iOS 这种面向对象编程的开发模式来说，我们应该遵循以下五个原则，即 SOLID 原则。

单一功能原则：对象功能要单一，不要在一个对象里添加很多功能。
开闭原则：扩展是开放的，修改是封闭的。
里氏替换原则：子类对象是可以替代基类对象的。
接口隔离原则：接口的用途要单一，不要在一个接口上根据不同入参实现多个功能。
依赖反转原则：方法应该依赖抽象，不要依赖实例。iOS 开发就是高层业务方法依赖于协议。
同时，遵守这五个原则是开发出容易维护和扩展的架构的基础。

梳理组件之间的逻辑关系，进行改造。

而对于组件间如何分层这个问题，我认为层级最多不要超过三个，你可以这么设置：
底层可以是与业务无关的基础组件，比如网络和存储等；
中间层一般是通用的业务组件，比如账号、埋点、支付、购物车等；
最上层是迭代业务组件，更新频率最高。

两种架构设计方案：

1、协议式：

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

2、中间者：

另一种常用的架构形式是中间者架构。它采用中间者统一管理的方式，来控制 App 的整个生命周期中组件间的调用关系。同时，iOS 对于组件接口的设计也需要保持一致性，方便中间者统一调用。

更多的还是需要在功能逻辑和组件划分上做到同层级解耦，上下层依赖清晰，这样的结构才能够使得上层组件易插拔，下层组件更稳固。而中间者架构模式更容易维护这种结构，中间者的易管控和易扩展性，也使得整体架构能够长期保持稳健与活力。所以，中间者架构就是我心目中好的架构。

PS：到现在为止，以前很少考虑到架构这块，以后的学习和工作需要往这块发展了。加油！！！