DDD实战基础

 

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

 

 

DDD总体结构分为四层  :  Interfaces(用户接口层，也叫用户界面层或是接口层)，Application(应用层)，Domain(领域层)，Infrastructure(基础层)，分层架构各层的职责边界非常清晰，又能有条不紊地分层协作。下面介绍下各个层面的作用。

 

微服务一级目录结构

微服务一级目录是按照 DDD 分层架构的分层职责来定义的。从下面这张图中，我们可以看

到，在代码模型里分别为用户接口层、应用层、领域层和基础层，建立了 interfaces、

application、domain 和 infrastructure 四个一级代码目录。

 

Interfaces（UI）层:

它主要存放与前端交互、展现数据的相关代码。前端应用通过这一层的接口，向应用服务获取展现所需的数据。这一层主要用来处理用户发送的 Restful 请求，解析配置信息，并将数据传递给 Application 层。数据的组装等代码都会放在这一层目录里。接口的主要工作就是将一个用户请求委派给一个或多个service进行处理，就是之前的controller。

Interfaces主要包括以下内容：

Controller 为远程客户端提供粗粒度的接口。

dto（数据传输对象）它是数据的载体，它内部不存在任何业务逻辑 ，作用就是把内部的领域对象与外界隔离，

Application层:

它的主要作用就是组合和编排应用层服务的相关代码。应用服务向下调用微服务内的领域服务或外部微服务的应用，完成服务的编排、组合，完成业务逻辑等任务。向上为用户接口层提供数据展现支持。应用服务和事件等代码会放在这一层目录里。（应用层中的服务调用本聚合中的服务时直接调用该聚合下属的领域服务，当需调用其他聚合中的领域服务或其他微服务时应调用其他聚合在应用层发布的事件接口。）

应用层主要包括以下内容：

对象转换convert（负责将ui层的dto转换为领域对象Entity。实现dto与领域对象的相互转换）

事件event（ 用于存放本应用服务调用其他聚合的领域服务或其他微服务所暴露的事件接口）

服务service（用于完成服务的编排、组合，完成业务逻辑任务）

Validator 用于数据校验

Domain层:

 

Domain是系统的业务核心。它主要存放领域层核心业务逻辑相关的代码。领域层包含多个聚

合它们共同实现领域模型的核心业务逻辑。聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。它是整个系统的核心层,几乎全部的业务逻辑会在该层实现。

领域模型层中不同聚合存放在自己独立的包目录中，每个聚合包目录包括以下内容：

聚合（聚合的组成原则是将业务和逻辑紧密关联的实体和值对象组合在一起，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储以实现数据的持久化。）

领域驱动设计强调业务单一职责以实现高内聚聚低耦合，就是把相关的行为聚集在一起，把不相关的行为放在别处，如果要修改某个服务的行为，就只需在一处修改。不需要修改其它服务实现松耦合。一个松耦合的服务应该尽可能少的知道与之协作的那些服务的信息。为之后的拆分、扩展提供便利。也方便之后程序员快速理解业务逻辑。

每个聚合中包括：

实体 Entity

值对象objectValue（无需唯一标识符的对象）。

转换器convert （entity转po）

         领域服务service（一些行为无法归类到实体对象或值对象上则放入service中）

         事件Event  当需要暴露本领域服务给应用层的其他聚合调用时在本层暴露接口

         工厂factory 创建复杂对象，隐藏创建细节。

         仓储repository（提供查询和持久化对象的方法）

Infrastructure层:

它主要存放基础资源服务相关的代码，为其它各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码。

         基础设施层主要包括：为应用层 传递消息（比如通知）

         为领域层 提供持久化机制（底层的实现）

         为用户界面层 提供组件配置

         基础设施层还能够通过架构框架来支持四个层次间的交互模式

业务逻辑从领域层、应用层到用户接口层逐层封装和协作，对外提供灵活的服务，各层的分工协作。

 

 

服务的封装与组合