一、背景
业务组件化（或者叫模块化）作为移动端应用架构的主流方式之一，近年来一直是业界积极探索和实践的方向。有赞移动团队自16年起也在不断尝试各种组件化方案，在有赞微信商城，有赞零售，有赞美业等多个应用中进行了实践。我们踩过一些坑，也收获了很多宝贵的经验，并沉淀出 iOS 相关框架 Bifrost (雷神里的彩虹桥)。在过程中我们深刻体会到“没有绝对正确的架构，只有最合适的架构”这句话的意义。
iOS 组件化/模块化的方案有很多，我们只提供一种实现思路，对遇到类似问题的同学能有所启发，并不准备对组件化架构设计方案给出一份标准答案。区别于功能模块/组件（比如图片库，网络库），本文讨论的是业务模块/组件（比如订单模块，商品模块）相关的架构设计。
二、 业务模块化/组件化传统的 App 架构设计更多强调的是分层，基于设计模式六大原则之一的单一职责原则，将系统划分为基础层，网络层，UI层等等，以便于维护和扩展。但随着业务的发展，系统变得越来越复杂，只做分层就不够了。App 内各子系统之间耦合严重, 边界越来越模糊，经常发生你中有我我中有你的情况（图一）。这对代码质量，功能扩展，以及开发效率都会造成很大的影响。此时，一般会将各个子系统划分为相对独立的模块，通过中介者模式收敛交互代码，把模块间交互部分进行集中封装, 所有模块间调用均通过中介者来做（图二）。这时架构逻辑会清晰很多，但因为中介者仍然需要反向依赖业务模块，这并没
