组件化方案

为什么需要组件化

在一个项目越来越大，开发人员越来越多的情况下，项目会遇到很多问题。

• 业务模块间划分不清晰，模块之间耦合度很大，非常难维护
• 所有模块代码都编写在一个项目中，测试某个模块或功能，需要编译运行整个项目

组件化的好处

• 业务划分更佳清晰，新人接手更佳容易，可以按组件分配开发任务
• 项目可维护性更强，提高开发效率
• 更好排查问题，某个组件出现问题，直接对组件进行处理
• 开发测试过程中，可以只编译自己那部分代码，不需要编译整个项目代码
• 方便集成，项目需要哪个模块直接通过CocoaPods集成即可
• 进行组件化开发后，可以把每个组件当做一个独立的app，每个组件甚至可以采取不同的架构，例如分别使用MVVM、MVC、MVCS等架构
• 多业务的并行集成，多部门的业务输出

方案介绍

组件化架构.png

三层架构

组件化架构在物理结构上来说是不分层次的，只是组件与组件之间的依赖关系。但是在组件化架构的基础上，应该根据项目和业务设计自己的层次架构，这套层次架构可以用来区分组件所处的层次及职责，所以我们设计了层级架构+组件化架构的架构。

所以可以拆分为三层架构：业务层 -> 核心层 -> 基础层 。基础层、核心层、业务层。基础层模块比如像网络框架、持久化、Log、社交化分享这样的模块，这一层的模块我们可以称之为组件，具有很强的可重用性。中间层模块可以有登录模块、网络层、资源模块等，这一层模块有一个特点是它们依赖着基础组件但又没有很强的业务属性，同时业务层对这层模块的依赖是很强的。业务层模块，就是直接和产品需求对应的模块了，比如类似朋友圈、直播、Feeds流这样的业务功能了。

在分层架构中，需要注意只能上层对下层依赖，下层对上层不能有依赖，下层中不要包含上层业务逻辑。对于项目中存在的公共资源和代码，应该将其下沉到下层中。

架构设计思考

在三层架构中，业务层用来处理上层业务，例如四六级模块、考研模块、我的模块等。这些模块的组件间关系比较复杂，会涉及到业务组件之间的关系，以及业务层对下层核心层组件的引用。

在设计核心层时就需要注意了，核心层需要为上层提供业务支持，而且应该遵循“高内聚，低耦合”的设计规范。核心层组件应该调用方便，而且对上层无依赖，不需要上层做太多的处理即可完成任务。核心层为业务层提供业务支撑，封装网络、数据库等核心模块，实现真正意义上的核心。

核心层的设计应该尽量无耦合，但是并不能做到完全无耦合。例如核心层的分享和网络两个同级组件，分享可能会调用到网络的代码，例如分享成功后向公司服务器发送请求，这时候就不可避免的产生核心层组件间的引用。

一些和业务无关的模块，也就是纯技术的模块，应该放在基础层中当做基础组件。基础组件包含加密、基础网络库(AFNetworking)、图片库(SDWebImage)等模块，在基础层中的各个组件间不应该有任何耦合，如果有耦合也只能发生在核心层和业务层。

基础层的组件应该符合“单一职责”的原则，即当前组件只负责和组件相关的事，不会包含其他不相关的代码。例如分享中不应该包含网络请求，如果包含则放在核心层中。

对于核心层和基础层的划分，可以以是否涉及业务、是否涉及同级组件间通信、是否经常改动为参照点。如果符合这几点则放在核心层，如果不符合则放在基础层。

业务层解耦

所以应该做的是，只让其他模块对中间层产生耦合关系，中间层不对其他模块发生耦合。
对于这个问题，可以采用组件化的架构，将每个模块作为一个组件。并且建立一个主项目，这个主项目负责集成所有组件。这样带来的好处是很多的：

• 业务划分更佳清晰，新人接手更佳容易，可以按组件分配开发任务
• 项目可维护性更强，提高开发效率
• 更好排查问题，某个组件出现问题，直接对组件进行处理
• 开发测试过程中，可以只编译自己那部分代码，不需要编译整个项目代码
• 方便集成，项目需要哪个模块直接通过CocoaPods集成即可

业务层解耦.png

解耦方案

对于中间件的设计方案，目前国内讨论比较火热的就两种。一种是URL+Procotol，另一种则是Target-Action。

基于URL注册调度的方案存在两个问题：

1. 命名域渗透
2. 因注册是不必要的，而带来同样不必要的注册列表维护成本

因此我们采用casatwy的第三方开源组件CTMediator作为用来解耦业务组件的中间件。

参考资料

组件化架构漫谈

iOS 组件化方案探索

iOS组件化方案

iOS应用架构谈 组件化方案