项目大了人员多了，架构怎么设计更合理？
架构是需要一步步演进的，如果项目规模大了还不演进，必然会拖累业务的发展速度。
从简单架构往大型项目架构演进中，需要解决三个问题：
- 模块粒度如何划分
- 如何分层
- 多团队如何协作
模块粒度如何划分
模块粒度划分是一个细活，最好可以在不同阶段采用不同的粒度划分模块。模块划分时需要遵循五个原则，即 SOLID 原则：
- 单一功能原则：对象功能要单一，不要在一个对象里添加很多功能；
- 开闭原则：对扩展开放，对修改封闭；
- 里氏替换原则：子类对象可以替代基类对象；
- 接口隔离原则：接口用途要单一，一个类对另一个类的依赖性应建立在最小接口上；
- 依赖反转原则：方法应该依赖抽象，不要依赖实例。iOS 开发就是高层业务方法依赖于协议；
如何分层
戴铭老师的建议是最多不要超过三层，可以这么设置：
- 底层是与业务无关的基础组件，比如网络和存储等；
- 中间层是通用的业务组件，比如账号、埋点、支付、购物车等；
- 最上层是迭代的业务组件，更新频率最高；
多团队之间如何分工
一个合理的团队结构应该是这样的：
- 首先，需要一个专门的基建团队，负责业务无关的基础功能组件和通用业务组件的开发；
- 然后，每个业务都有一个专门的团队负责开发。业务可以按照功能耦合度来划分，耦合度高的业务划分成一个单独的业务团队，比如机票业务单独一个团队，酒店业务单独一个团队；
- 基建团队人员应该是流动轮岗的，从业务团队里来，再回到业务团队里去。
总结来说，团队分工还是要灵活，不能太隔离固化了，团队分工还是要围绕具体的业务进行功能模块提炼，提炼的通用模块下沉，然后做精做扎实。
好的架构是什么样的
在实践中，一般分为协议式和中间者两种架构设计方案。 协议式架构主要采用协议式编程的思路：在编译层面使用协议定义规范，实现可在不同地方，从而达到分布管理和维护组件的目的。但缺点也很明显，主要体现在：
- 缺少统一调度，导致难以集中管理。
- 接口定义模式过于规范，导致灵活度不够高。
中间者架构主要采用中间者统一管理的方式，来控制 App 的整个生命周期中组件间的调用关系。同时组件接口设计也需要保持一致性，方便中间者统一调用。个人感觉中间者架构更好一些。
Router 架构参考： MGJRouter ，中间者架构参考： CTMediator ； 戴铭老师基于 CTMediator 做了一些优化： ArchitectureDemo
架构/组件化方面的博客：
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论