整体架构
架构分三层，从下至上依次为：
根底层，服务层，事务层
根底层：与 app 不相关的根底功能，任何 app 都能够接入。
服务层：服务于事务，一些通用组件和对根底模块的封装。
事务层：对事务模块的封装
组件管理
组件管理现在的方式有几种
- Swift Package Manager
- Carthage / CocoaPods
- 静态库工程
SPM 是苹果新推出的，因为要混编，迁移本钱高，pass。
当时项目是根据 CocoaPods 的，Carthage pass。
CocoaPods VS 静态库
CocoaPods 接入简单，母工程影响小，但是制造费事。
静态库联編 制造简单，接入费事，能够躲藏要害代码。
编译依靠
- Git submodel
- Git subtree
- Cocoapods
定论
根底层 和 服务层一概入库，接入 Cocoapods，要能支撑最小化接入。
事务组件暂时不做物理隔离，有必要做的做成 developmentPod 简化联调作业。
层级间拜访准则
纵向
纵向层级之间单向依靠，拒绝跨层拜访。层级之间运用接口通讯，遵从依靠倒置准则。
横向
事务层间通讯统一运用路由或者音讯总线拜访，每个事务模块定义好自己的音讯署理和外部音讯处理事件。
组件通讯计划
业界干流的三种计划
- 根据 URLgithub.com/meili/MGJRo…
- 根据 Target-Actiongithub.com/casatwy/CTM…
- 根据 Protocolgithub.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 作为咱们的通用架构，在进行粒度拆分的一起考虑团队实际的状况。
以上为大概想法，实际过程中还有很多细节问题，还需要团队内部讨论，引证一句话
没有完美的架构，只要刚好的架构，没有满意一切的架构，只要满意目标的架构
