模块化架构设计

 

前言

架构设计是一个不断演变的过程，当项目较小，或者项目刚刚起步的阶段，我们往往不需要关注架构设计，只有当软件膨胀到一定程度，我们才会针对当前业务，设计出适合当前阶段的架构。所以有的项目就会出现不断膨胀，不断重构的情况。那为什么不一开始就设计一个大而全的架构？我认为有以下几点：

1、架构是对当前业务进行的一层抽象，当业务不稳定，或者在高速迭代的过程中，我们没办法定义出稳定的抽象层。导致哪怕架构设计好，也会在业务迭代的过程中被破坏。

2、架构的过程事实上也是一个解耦的过程，而解耦越充分，相应的也会导致代码量膨胀、代码开发难度变大，所以在项目不是太复杂的阶段，适当的耦合可以提高开发效率。

 

适用项目

那什么样的情况适用架构设计呢？我认为以下几种情况可以考虑使用模块化重构项目：

1、多人协作开发的情况

2、项目足够复杂，且当前架构下很难进行维护

3、有插件化或者按需加载需求的项目

 

目标

 

架构目标

 

1、安全性和可靠性

软件运行不引起系统事故的能力，在模块化中当某一个模块出现异常，框架可以保证在不使用该模块能力的情况下正常运行。

 

2、可伸缩性和可扩展性

对于新增模块，或者移除模块项目的改动较少，我们可以通过较少的改动线性的增加需要，大多数情况下只需要简单的配置。

 

3、可定制性

可临时对架构能力进行扩展，或者能力的重新实现，来达到不同环境下使用的需要。这样的架构设计可以适用于更多的项目中使用。

 

4、可维护性

保证模块内高内聚，模块间低耦。

 

模块目标

 

1、可独立运行

模块可以作为一个独立的APP，运行使用。

 

2、可插拔

模块的插拔对项目无影响，只是能力的可用和无响应的区别。

 

3、可移植

模块可以通过简单的适配移植到其他项目中使用，与运行环境完全隔离。

 

架构设计

 

 

架构图

 

 

架构图解读

和大多数模块化不同，架构设计中我采用了两层抽象，一方面将项目APP与具体业务解耦，另外一方面将单个模块与框架能力解耦。APP层不再关心业务实现，它只负责业务模块的初始化、生命周期的调用、及适配业务模块所依赖的接口能力。

项目在编译期不再依赖具体的业务模块，而只在打包时候才会将业务模块打包进APK，所以在开发过程中我们无法感知到其他业务模块的存在。

在开发具体的业务模块时，我们无法感知到当前模块在哪个项目中，我们只能依赖