“这是我参与更文挑战的第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或者架构师就应该发挥作用了，当然这也得看公司领导层是否重视这块，不然在代码质量层面就走远了。

初创型公司软件孵化（四）