整体架构
架构分三层，从下至上依次为：
基础层，服务层，业务层
基础层：与 app 不相关的基础功能，任何 app 都可以接入。
服务层：服务于业务，一些通用组件和对基础模块的封装。
业务层：对业务模块的封装
组件管理
组件管理现在的方式有几种
- Swift Package Manager
- Carthage / CocoaPods
- 静态库工程
SPM 是苹果新推出的，因为要混编，迁移成本高，pass。
当前项目是基于 CocoaPods 的，Carthage pass。
CocoaPods VS 静态库
CocoaPods 接入简单，母工程影响小，但是制作麻烦。
静态库联編 制作简单，接入麻烦，可以隐藏关键代码。
编译依赖
- Git submodel
- Git subtree
- Cocoapods
结论
基础层 和 服务层一律入库，接入 Cocoapods，要能支持最小化接入。
业务组件暂时不做物理隔离，必须做的做成 developmentPod 简化联调工作。
层级间访问原则
纵向
纵向层级之间单向依赖，拒绝跨层访问。层级之间使用接口通信，遵循依赖倒置原则。
横向
业务层间通信统一使用路由或者消息总线访问，每个业务模块定义好自己的消息代理和外部消息处理事件。
组件通信方案
业内主流的三种方案
- 基于 URL github.com/meili/MGJRo…
- 基于 Target-Action github.com/casatwy/CTM…
- 基于 Protocol github.com/alibaba/Bee…
业务层横向架构
在说业务架构之前，我们看一下通常一个页面从打开到渲染完呈现在用户面前有哪些工作
- 视图创建
- 处理业务逻辑
- 发起网络请求
- 解析网络返回数据到业务数据
- 转换业务数据到视图数据
- 渲染视图数据
- UI 跳转工作
当前的项目架构是古老的 MVC 架构，iOS 的 MVC 其实比较鸡肋，View 形同虚设，基本所有工作都分摊在 Controller 和 Model 里，所以业内有 胖 Model 和 瘦 Model 的争论。
而后出现了一堆 MVC 的衍生类框架，将上述 1-7 种事务从 C 或 M 中拆到新的区域中，以此解决 Massive Controller 的问题。下图是常见的两种衍生框架 MVP 和 MVVM 与 MVC 的对比。由图上可见 Presenter 的关注点更多在页面逻辑，ViewModel 更关注的页面数据构造的过程。
说到MVCS的衍生框架就不得不提这里面的的佼佼者 VIPER
VIPER 在粒度拆分上面做到了极致，VIPER 的实现中有一些比较出色的框架如 Uber 的 Ribs，打开示例工程你就会发现事物都有两面性，细粒度的切分在耦合度降低的同时也会带来额外的工作量，太多的胶水代码，在不是很复杂的场景有种杀鸡用牛刀的感觉。
另外还有一些比较小众的框架，例如 Redux 在移动端的实现 ReSwift
例如一个用户登录服务就可以拆解成以下部分
黑猫白猫，能抓住耗子的就是好猫，找到适合场景的架构才能解决问题的根本。我们不排斥采用多架构，因为每种适合的场景不一样。我推荐使用 MVVM 作为我们的通用架构，在进行粒度拆分的同时考虑团队实际的情况。
以上为大概想法，实际过程中还有很多细节问题，还需要团队内部探讨，引用一句话
没有完美的架构，只有刚好的架构，没有满足一切的架构，只有满足目标的架构