SpringBoot多模块应用的模块设计

1、Starter模块

启动模块，所有的Congfig类也建议放在这里。为什么是所有的Config都放在这里，我认为放在这里使得配置类更加的集中，更加的好管理，也能更好的梳理配置，虽然有些配置也可以跟着自己的模块走，但是我还是觉得放在这里好些。有更多体会的建议留言。

2、Client模块/Facede模块

定义接口和出入参，微服务下，Controller可以实现一个FeignClient接口，这个接口的定义、出入参（Request、Response/Vo）的定义都放在单独的模块，这个模块可以被别的项目依赖，这样调用方可以避免写FeignClient。 这个模块不应该依赖工程的任何模块，建议只能被依赖。

3、Client-Impl/Controller模块

实现Client定义的接口，调用Service层实现业务逻辑。同时也负责出入参与Service层的出入参的转换。

4、Core-Service

业务逻辑层。出入参可以依赖一个Core-Model 模块，宽泛点的话也可以依赖Client模块的出入参。 如果业务逻辑非常复杂，业务逻辑层也可以分为两层，比如Biz-Manager和Biz-Service，共用逻辑沉淀到下层，上层做业务编排，如果业务不是很复杂，一个模块也行，用包区分下也可以。

5、Repository层

数据库访问层，出入参也是Model，因为他不直接操作数据库。依赖Dao层实现逻辑，由于使用的模型与Dao不一样，Convert层也在这里(DO -> Model)。

6、Common-Dao层

就是Mybatis的Dao代码，直接操作数据库的一层，他的返回只能是DO（入参可以是基本类型和Model），DO和Dao在一个模块里。

7、Common-Integration层

调用外界接口进行封装，提供Api给本应用用。建议只能被依赖。建议使用Model的模型，如果自定义模型，在本模块内。

8、Common-Util

自己写的工具类，建议只能被依赖。比如我们写的SpringContextUtil。

9、Core-infrastructure

基础设置层，比如与MQ、配置中心相关代码。正常来说，这个模块也是应该被Service依赖。但是有没有可能出现MQ来了，需要调Service的代码？这时候可以把MQ这个特例移到Service里，甚至Client-Impl。这个模块是否可以调Repository？我觉得可以，如果你写一些基建类的代码，切他们需要访问数据库，依赖就可以了。

不建议建意义太宽泛的Common模块，如果有需要我宁愿建一个Common-Constants模块。非必要不需要建的那么深，一般来说，一个父模块，下面一些子模块，两层足够了。

做过一个对接三方平台的项目，他是要对接多个功能类似的三方平台，业务场景上要求每个接口每个三方平台都有对应的实现。然后聚合封装后，对外提供统一的接口。所以他先定义了一些接口和模板方法，不同渠道有单独的模块去实现这个接口模块，然后整个都在一个大的父模块下，一共有3层，其他的很少有这么强的逻辑性需要很多层的。

依赖路径

Starter -> Client-Impl  -> Serice -> Repository -> Dao层

Serice -> Integration

Serice -> Common-Util

Serice -> Core-infrastructure