09、DDD分层架构与微服务代码模型

DDD分层架构与微服务代码模型

微服务代码模型

  • Interface(用户接口层):主要存放用户接口层与前端交互、展示数据相关的代码。用来处理用户发送的Restful请求,解析用户输入的配置文件,并将数据传递给Application层
  • Application(应用层):主要存放应用层服务组合和编排相关的代码。应用服务和事件等代码会放在这一层目录里。
  • Domain(领域层):主要存放领域层核心业务逻辑相关的代码。聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。
  • Infrastructure(基础层):主要存放基础资源服务相关的代码,为其他层提供通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层目录里。

1、用户接口层

  • Assembler:实现 DTO 与领域对象之间的相互转换和数据交换。一般来说 Assembler 与 DTO 总是一同出现。
  • Dto:它是数据传输的载体,内部不存在任何业务逻辑,我们可以通过 DTO 把内部的领域对象与外界隔离。
  • Facade:提供较粗粒度的调用接口,将用户请求委派给一个或多个应用服务进行处理

2、应用层

  • Event(事件):这层目录主要存放事件相关的代码。它包括两个子目录:publish 和 subscribe。前者主要存放事件发布相关代码,后者主要存放事件订阅相关代码(事件处理相关的核心业务逻辑在领域层实现)。
  • Service(应用服务):这层的服务是应用服务。应用服务会对多个领域服务或外部应用服务进行封装、编排和组合,对外提供粗粒度的服务。应用服务主要实现服务组合编排,是一段独立的业务逻辑。

3、领域层

  • Aggregate(聚合):它是聚合软件包的根目录,可以根据实际项目的聚合名称命名,比如权限聚合。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。聚合内实现高内聚的业务逻辑,它的代码可以独立拆分为微服务。
  • Entity(实体):存放聚合根、实体、值对象以及工厂模式(Factory)相关代码。实体类采用充血模型,同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。
  • Event(事件):存放事件实体以及与事件活动相关的业务逻辑代码。
  • Service(领域服务):一个领域服务是多个实体组合出来的一段业务逻辑。领域服务封装多个实体或方法后向上层提供应用服务调用。
  • Repository(仓储):存放所在聚合的查询或持久化代码,通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合,我们设定了一个原则:一个聚合对应一个仓储。

4、基础层

Infrastructure 的代码目录结构有:config 和 util 两个子目录。

Config主要存放配置相关代码;Util主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、三方类库、通用算法等基础代码,你可以为不同的资源类别建立不同的子目录。

总结

第一点:聚合之间的代码边界一定要清晰。在以后业务发展和需求变更时,可以很方便地实现业务功能和聚合代码的重组,在微服务架构演进中将会起到非常重要的作用。

第二点:一定要有代码分层的概念,搞清楚代码的职责,将它放在职责对应的代码目录内。如果将核心领域逻辑代码放到应用层,微服务慢慢就会演变成传统的三层架构模型了。

你可能感兴趣的:(09、DDD分层架构与微服务代码模型)