前言
架构设计是一个不断演变的过程,当项目较小,或者项目刚刚起步的阶段,我们往往不需要关注架构设计,只有当软件膨胀到一定程度,我们才会针对当前业务,设计出适合当前阶段的架构。所以有的项目就会出现不断膨胀,不断重构的情况。那为什么不一开始就设计一个大而全的架构?我认为有以下几点:
1、架构是对当前业务进行的一层抽象,当业务不稳定,或者在高速迭代的过程中,我们没办法定义出稳定的抽象层。导致哪怕架构设计好,也会在业务迭代的过程中被破坏。
2、架构的过程事实上也是一个解耦的过程,而解耦越充分,相应的也会导致代码量膨胀、代码开发难度变大,所以在项目不是太复杂的阶段,适当的耦合可以提高开发效率。
适用项目
那什么样的情况适用架构设计呢?我认为以下几种情况可以考虑使用模块化重构项目:
1、多人协作开发的情况
2、项目足够复杂,且当前架构下很难进行维护
3、有插件化或者按需加载需求的项目
目标
架构目标
1、安全性和可靠性
软件运行不引起系统事故的能力,在模块化中当某一个模块出现异常,框架可以保证在不使用该模块能力的情况下正常运行。
2、可伸缩性和可扩展性
对于新增模块,或者移除模块项目的改动较少,我们可以通过较少的改动线性的增加需要,大多数情况下只需要简单的配置。
3、可定制性
可临时对架构能力进行扩展,或者能力的重新实现,来达到不同环境下使用的需要。这样的架构设计可以适用于更多的项目中使用。
4、可维护性
保证模块内高内聚,模块间低耦。
模块目标
1、可独立运行
模块可以作为一个独立的APP,运行使用。
2、可插拔
模块的插拔对项目无影响,只是能力的可用和无响应的区别。
3、可移植
模块可以通过简单的适配移植到其他项目中使用,与运行环境完全隔离。
架构设计
架构图
架构图解读
和大多数模块化不同,架构设计中我采用了两层抽象,一方面将项目APP与具体业务解耦,另外一方面将单个模块与框架能力解耦。APP层不再关心业务实现,它只负责业务模块的初始化、生命周期的调用、及适配业务模块所依赖的接口能力。
项目在编译期不再依赖具体的业务模块,而只在打包时候才会将业务模块打包进APK,所以在开发过程中我们无法感知到其他业务模块的存在。
在开发具体的业务模块时,我们无法感知到当前模块在哪个项目中,我们只能依赖