- 首先定义 工程开发模式 ，
苹果官方推荐的 App 开发模式是 MVC，随之衍生出其他很多类 MVC 的设计模式 MVP、MVVM、MVCS ，它们在不同程度上增强了视图、数据的通信方式，使得逻辑、视图、数据之间的通信更灵活、规整、易于扩展。在 App 浪潮初期，几乎所有 App 采用的都是这种类 MVC 的结构。原因在于，MVC 是很好的面向对象编程范式，非常适合个人开发或者小团队开发。但是，项目大了，人员多了以后，这种架构就扛不住了。
所以，接下来我们就不得不考虑模块粒度如何划分、如何分层，以及多团队如何协作这三个问题了。解决了这三个问题以后，我们就可以对模块内部做进一步优化了。模块久经考验后，就能成为通用功能对外部输出，方便更多的团队。 在结合了目前iOS项目的开发语言是 OC 以及 公司项目团队的技术力量等综合考虑 决定采用 MVVM 架构开发 。 - 对于组件化， 划分的 规则 是什么
对于 模块粒度应该怎么划分
对于 iOS 这种面向对象编程的开发模式来说，我们应该遵循以下五个原则，即 SOLID 原则。
· 单一功能原则：对象功能要单一，不要在一个对象里添加很多功能。
·开闭原则：扩展是开放的，修改是封闭的。里氏替换原则：子类对象是可以替代基类对象的。
·接口隔离原则：接口的用途要单一，不要在一个接口上根据不同入参实现多个功能。
·依赖反转原则：方法应该依赖抽象，不要依赖实例。iOS 开发就是高层业务方法依赖于协议。
同时，遵守这五个原则是开发出容易维护和扩展的架构的基础。
组件解耦并不是说要求每个组件间都没有耦合，组件间也需要有上下层依赖的关系。组件间的上下层关系划分清楚了，就会容易维护和管理。而对于组件间如何分层这个问题，我认为层级最多不要超过三个，你可以这么设置：底层可以是与业务无关的基础组件，比如网络和存储等；中间层一般是通用的业务组件，比如账号、埋点、支付、购物车等；最上层是迭代业务组件，更新频率最高。
目前就韵镖侠而言 暂时分为 分为 签收 揽收 两大块 和其他模块（具体工具模块 还可以划分）（至于签收揽收 还需要具体划分， 暂时由业务部门负责提出 ，咱们在谈论 ）
但是，我认为不用把所有的功能都做成组件，只有那些会被多个业务或者团队使用的功能模块才需要做成组件。因为，改造成组件也是需要时间成本的，很少有公司愿意完全停下业务去进行重构，而一旦决定某业务功能模块要改成组件，就要抓住机会，严格按照 SOLID 原则去改造组件，因为返工和再优化的机会可能不会再有。
-
对于 组件化 最大的考量是 中间件的 取舍
目前iOS组件考虑较多的有 协议式和中间者两种架构设计方案。
3.1 协议式架构设计主要采用的是协议式编程的思路
在编译层面使用协议定义规范，实现可在不同地方，从而达到分布管理和维护组件的目的。这种方式也遵循了依赖反转原则，是一种很好的面向对象编程的实践。
但是，这个方案的缺点也很明显，主要体现在以下两个方面：由于协议式编程缺少统一调度层，导致难于集中管理，特别是项目规模变大、团队变多的情况下，架构管控就会显得越来越重要。协议式编程接口定义模式过于规范，从而使得架构的灵活性不够高。当需要引入一个新的设计模式来开发时，我们就会发现很难融入到当前架构中，缺乏架构的统一性。虽然协议式架构有这两方面的局限性，但由于其简单易用的特点依然被很多公司采用。
3.2 另一种常用的架构形式是中间者架构。它采用中间者统一管理的方式，来控制 App 的整个生命周期中组件间的调用关系。同时，iOS 对于组件接口的设计也需要保持一致性，方便中间者统一调用。
中间者架构如下图所示：
40a625a0f556aa264eee9fbb212b3469.png
可以看到，拆分的组件都会依赖于中间者，但是组间之间就不存在相互依赖的关系了。由于其他组件都会依赖于这个中间者，相互间的通信都会通过中间者统一调度，所以组件间的通信也就更容易管理了。在中间者上也能够轻松添加新的设计模式，从而使得架构更容易扩展。
在考虑架构设计时，我们更多的还是需要在功能逻辑和组件划分上做到同层级解耦，上下层依赖清晰，这样的结构才能够使得上层组件易插拔，下层组件更稳固。而中间者架构模式更容易维护这种结构，中间者的易管控和易扩展性，也使得整体架构能够长期保持稳健与活力。所以，中间者架构是最适合的架构。
