月度归档:2020年04月

Java微服务的模块划分

近段时间在推进公司内Java微服务的框架升级,有机会直面一线业务的很多服务,在这个过程中也发现一些有趣的事情:不同时间段,不同团队,大家对于Java服务的模块划分、模块或者Jar包发布、模块包的依赖管理做法都有所不同,今天正好借这篇文章,和大家聊一下。

从再熟悉不过的模块结构划分开始

在盘点业务服务时发现,大多数项目都采取了如下或者与之类似的项目模块结构:

  • business-api —— 对外发布的API接口,例如Dubbo协议的Service
  • business-dao —— 数据访问对象,多数项目使用了MyBatis,这里是Mapper的聚集地
  • business-model —— 模型,包括各类的实体、DTO等
  • business-service —— 业务逻辑层,包括各类Service、接口、实现等
  • business-web —— Web请求处理层,包括Controller等

它的命名规则可以概括为<服务名>-<模块名>,除了上面列出的模块外,常见的可能还有像business-core、business-common等。这种模块划分模式很常见,在大量的Java服务项目中得以采用。模块划分的依据也就是应用的分层结构,例如阿里巴巴的Java开发手册中推荐的应用分层模式为:

来自阿里巴巴Java开发手册,建议的应用分层

我们可以把这种类型的项目模块划分看做对这种分层模式的一种落地,所以要探讨模块划分的问题,我们需要先了解一下应用分层模式的由来。

继续阅读