“这是我参与更文挑战的第4天,活动详情查看: 更文挑战”
架构设计
应用架构
公共模块设计
定义
- 什么是公共模块?它来源于多个模块都会用到的代码块或逻辑,将其抽取并封装成独立的模块,在需要的时候引入即可,提高代码的复用性,减少重复代码量,提高代码的可维护性。
设计原则
-
说到公共模块的设计原则,这是一个比较有意思的话题,有的人觉得公共模块应该是完全自主开发,拒绝使用第三方的,因为存在不可控的因素,比如
license
、存在未知的风险(印象比较深刻的就是18年Ant Design 圣诞节彩蛋事件,当然这里不是说Ant Design
不好,毕竟是人都会犯错的。感兴趣的同学可以去看看);有的人觉得应该市面上很好的解决方案可以集成进来,这样可以专注于业务领域。当然存在一定风险,需要前期对其做好功课; -
针对于初创型公司来讲笔者认为应该结合这两种方案,一方面掌握自主开发的边界。毕竟初创型公司刚开始完全自主不现实的。另一方面集成业内比较著名的且版本相对比较稳定,且开源协议比较友好的。
后端以java web
为例。
1、统一的版本
- 方便后续统一管理与维护
2、公共模块之间避免多重依赖
- 如a模块被b模块引用,b模块被c模块应用,允许适当依赖
3、边界清晰
- 以下举例说明
// 反例
-- xxx-common
-- xxx-common-redis
-- xxx-common-idempotent
-- xxx-common-lock
// 正例(一)
-- xxx-common
-- xxx-common-idempotent
-- xxx-common-lock
// 正例(二)
-- xxx-common
-- xxx-common-redis
4、职责单一
- 避免为了使用一个功能,导致引用了很多无用的逻辑或jar包,增大项目体积,后续冲突情况。
5、拆分维度统一
- 一下举例说明方面理解仅供参考,开发中还需更加实际情况而定
5.1 根据集成维度
-- xxx-common
-- xxx-common-support
-- xxx-common-mybatis
-- xxx-common-redis
-- xxx-common-spring
5.2 根据功能维度
-- xxx-common
-- xxx-common-api
-- xxx-common-entity
-- xxx-common-dto
-- xxx-common-idempotent
-- xxx-common-lock
-- xxx-common-feign
5.2 根据类型维度
-- xxx-common
-- xxx-common-spurt
-- xxx-common-enums
-- xxx-common-config
-- xxx-common-exception
-- xxx-common-constant
-- xxx-common-cache
6、封装程度
项目之初不建议过度封装,尤其是在业务不是很熟悉的情况下对业务进行高度封装抽取,原因一:或许有些模块都用不上,原因二:增加了coder对项目熟悉的难度,增大了学习成本。刚开始建议简单抽取,可以在开发过程中慢慢改进,当然有人会说,都已经进入开发阶段了都没有时间和精力去维护和优化公共模块,不可否认确实如此,大部分都是这样的情况,这时候技术leader或者架构师就应该发挥作用了,当然这也得看公司领导层是否重视这块,不然在代码质量层面就走远了。