DDD领域驱动设计实战-分层架构及代码目录结构

Posted m0_69377236

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了DDD领域驱动设计实战-分层架构及代码目录结构相关的知识，希望对你有一定的参考价值。

[](()1.1 分层架构的基本原则

每层只与位于其下方的层发生耦合。

[](()1.2 分层架构的分类

  • 严格分层架构(Strict Layers Architecture)

某层只能与其直接下层耦合，即我的奴隶的奴隶，不是我的奴隶。

  • 松散分层架构(Relaxed Layers Architecture)

允许任意上层与任意下层耦合。由于用户接口层和应用服务通常需要与基础设施打交道，许多系统都是该架构。

较低层有时也可与较高层耦合，但只限于采用观察者 (Observer)模式或者调停者(Mediator)模式场景。

较低层绝不能直接访问较高层。例如，在使用调停者模式时，较高层可能实现了较低 Java开源项目【ali1024.coding.net/public/P7/Java/git】 层的接口，然后将实现对象作为参数传递到较低层。当较低层调用该实现时， 它并不知道实现出自何处。

[](()1.3 分层架构演进

[](()1.3.1 传统四层架构

将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层逻辑的依赖，因为它们不属业务逻辑。将一个夏杂的系统分为不同的层，每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。

传统分层架构的基础设施层位于底层，持久化和消息机制便位于该层。

这里的消息包含

  • MQ消息

  • SMTP

  • 文本消息(SMS)

可将基础设施层中所有组件看作应用程序的低层服务，较高层与该层发生耦合以复用技术基础设施。即便如此，依然应避免核心的领域模型对象与基础设施层直接耦合。

[](()1.3.2 改良版四层架构

[](()传统架构的缺陷

DDD初创开发团队发现，将基础设施层放在最底层存在缺点，比如此时领域层中的一些技术实现就很困难：

  • 违背分层架构的基本原则

  • 难以编写测试用例

何解？

使用依赖反转设计原则：低层服务（如基础设施层）应依赖高层组件（比如用户界面层、应用层和领域层）所提供的接口。

[](()应用依赖反转原则

  • 依赖反转原则后的分层方式：基础设施层在最上方，可实现所有其他层中定义的接口

依赖反转原则真的可以支持所有层吗？ 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》开源

有人认为依赖反转原则中只存在两层：最上方和最下方，上层实现下层定义的抽象接口。因此上图的基础设施层将位于最上方，而用户接口层、应用层和领域层应作同层且都位于下方。对此大家可保留自己意见。

[](()2 各层职责

=====================================================================

[](()2.1 Interfaces（用户接口层）

一般包括用户接口、Web 服务等。

只处理用户显示和用户请求，不应包含领域或业务逻辑。

有人认为，既然用户接口需验证用户输入，就无可避免应该包含业务逻辑。事实上，用户接口所进行的验证和对领域模型的验证不同：对那些粗制滥造且只面向领域模型的验证行为，应该予以限制。

如果用户接口使用了领域模型中的对象，那么此时领域对象仅限于数据渲染展现。在采用这种方式时，可使用展现模型对用户接口与领域对象进行解耦。

由于用户可能是人，也可能是其他系统，有时用户接口层将采用开放主机服务的方式向外提供API。

用户接口层是应用层的直接用户。

用户接口层在于前后端调用的适配。若你的微服务要提供服务给很多外部应用，而对每个外部应用的入参出参都不同，你不可能开发一堆一对一的应用服务，这时Facade接口就起到了很好的作用，包括DO和DTO对象的组装和转换。

由于主要负责接入各种终端，所以该层有人也叫接入层。

实际开发中，我们都会感受到该层依附于应用层存在。随前后端分离，Restful API 流行，对简单的系统来说该层越来越弱化。对于有终端接入的系统来说，该层并不简单，需要处理各种协议适配：XMPP、websocket、MQTT 等。

复杂度不高时，我们往往把该层和应用层合并部署，主要凭开发经验和理解程度来决定。

存放用户接口层与前端交互、展现数据相关的代码。

前端应用通过这层接口，向应用服务获取展现所需的数据。

该层主要用来处理用户发送的Restful请求，解析用户输入的配置文件，并将数据传递给应用层。

数据的组装、数据传输格式以及Facade接口等代码都会放在这一层目录里。

封装应用服务和对外暴露接口。

[](()特点

  • 关心视图和对外的服务，Restful、页面渲染、websocket、XMPP 连接等

  • 如果没有多种用户端接入方式，可以和应用层合并

  • 对应到分布式系统中的网关、BFF、前台等概念

  • 只产生接入异常，例如数据校验，对应 HTTP 状态码 400、415 等

  • 一个应用可以有多个接入层

  • 接入层做和业务规则无关的 bean validation 验证

  • 准单体系统下，按照连接方式分包

该层指的是服务端用于适配端侧的部分，而非端侧本身。因为该层本就依赖应用层，无人使用接口在这里做依赖倒置，所有又被称作主动适配。

[](()1.1 细分结构

  • assembler、dto 和 façade

[](()facade

提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。比如调用应用层创建用户的方法。

[](()dto

数据传输的载体，内部不存在任何业务逻辑，可以通过DTO把内部的领域对象与外界隔离。

比如接收请求传入的数据CustomerDTO。

不同的对象在不同的层转换。用户接口层DTO和DO转换，应用层主要是DO，调外部微服务的服务的时候应用层有dto和do的转换。领域层与基础层之间，在基础层有DO和PO的转换。

在接口层定义DTO对象。数据可能来源于多个DO对象。

[](()assembler

实现DTO与DO间的相互转换和数据交换。

一般assembler与dto一同出现。比如创建用户时，将CustomerDTO转换为CustomerEntity。你可以在用户接口层创建DTO类和assembler类。在assembler类里完成映射。

[](()2.2 应用层

[](()特点

  • 关心处理完一个完整的业务

  • 该层只负责业务编排，对象转换，实际业务逻辑由领域层完成

  • 不关心【请求从何处来】，但是关心【谁来、做什么、有没有权限做】

即复制安全认证、权限校验

  • 集成不同的领域服务解决问题

应用层位于领域层之上，因为领域层包含多个聚合，所以它可协调多个聚合服务和领域对象完成服务编排和组合，协作完成业务。

  • 最终一致性（最终一致性对业务有侵入）事务放到这层

  • 对应到分布式系统中的中台等概念

  • 方法级别的功能权限控制放到这层

  • 只产应用异常，对应 HTTP 状态码 403、401

  • 准单体系统下，按照应用划分模块

主要包含应用服务，理论上不应有业务规则或逻辑，而主要是面向用例和流程相关的操作。

  • 应用层也是微服务间的交互通道，它可调用其它微服务，完成微服务间的服务组合和编排。

开发设计时，不要将本该放在领域层的业务逻辑放到应用层。庞大的应用层会使领域模型失焦，时间一长，微服务就会退化为MVC。

应用服务是在应用层，负责

  • 服务的组合、编排、转发、转换和传递，处理业务用例的执行顺序以及结果的拼装，以粗粒度服务通过API网关发布到前端

  • 发送或订阅领域事件

[](()应用层代码目录结构

存放应用层服务组合和编排相关的代码。

应用服务向下基于

  • 微服务内的领域服务，或

  • 外部微服务的应用服务

完成服务的编排和组合

向上为用户接口层提供各种应用数据展现支持服务。

应用服务和事件等代码会放在这层目录。

[](()Event（事件）

主要存放事件相关代码。包括两子目录：

[](()publish

主要存放事件发布相关代码。比如发布用户创建事件给其它微服务。

[](()subscribe

主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）。

虽然应用层和领域层都可进行事件的发布和处理，但为实现事件的统一管理，推荐将微服务内所有事件的发布和订阅处理都统一放到应用层，事件相关的核心业务逻辑实现放在领域层。通过应用层调用领域层服务，来实现完整的事件发布和订阅处理流程。

[](()Service（应用服务）

应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。

可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。

比如内部服务->创建用户；外部服务->创建日志。

[](()2.3 领域层

主要包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。

实现核心业务逻辑，通过各种校验保证业务正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

领域模型的业务逻辑主要由实体和领域服务实现：

  • 实体采用充血模型 实现所有与之相关的业务功能。

实体和领域服务在实现业务逻辑上不是同级，当领域中的某些功能，单一实体或值对象无法实现，就会用到领域服务，它可组合聚合内的多个实体或值对象，实现复杂业务逻辑。

[](()3 Domain（领域层）

最后

每年转战互联网行业的人很多，说白了也是冲着高薪去的，不管你是即将步入这个行业还是想转行，学习是必不可少的。作为一个Java开发，学习成了日常生活的一部分，不学习你就会被这个行业淘汰，这也是这个行业残酷的现实。

如果你对Java感兴趣，想要转行改变自己，那就要趁着机遇行动起来。或许，这份限量版的Java零基础宝典能够对你有所帮助。

领域模型的业务逻辑主要由实体和领域服务实现：

  • 实体采用充血模型 实现所有与之相关的业务功能。

实体和领域服务在实现业务逻辑上不是同级，当领域中的某些功能，单一实体或值对象无法实现，就会用到领域服务，它可组合聚合内的多个实体或值对象，实现复杂业务逻辑。

[](()3 Domain（领域层）

最后

每年转战互联网行业的人很多，说白了也是冲着高薪去的，不管你是即将步入这个行业还是想转行，学习是必不可少的。作为一个Java开发，学习成了日常生活的一部分，不学习你就会被这个行业淘汰，这也是这个行业残酷的现实。

如果你对Java感兴趣，想要转行改变自己，那就要趁着机遇行动起来。或许，这份限量版的Java零基础宝典能够对你有所帮助。

[外链图片转存中…(img-r1FcPa9a-1650169995978)]

DDD 领域驱动设计实战（分层架构）

????????关注后回复 “进群” ，拉你进程序员交流群????????

作者丨JavaEdge在掘金

来源：

https://juejin.cn/post/6920458240165675022

  • 1 DDD分层架构

    • 1.1 分层架构的基本原则

    • 1.2 分层架构的分类

    • 1.3 分层架构演进

  • 2 各层职责

    • 2.1 用户接口层

    • 2.2 应用层

    • 2.3 领域层

    • 2.4 基础层

  • 3 微服务架构演进

    • 微服务架构的演进案例

    • 微服务内服务的演进

    • 三层架构如何演进到DDD分层架构？

  • 总结

整洁架构、CQRS、六边形架构等微服务架构都旨在“高内聚低耦合”。那DDD分层架构又如何？

1 DDD分层架构

1.1 分层架构的基本原则

每层只能与位于其下方的层发生耦合。

1.2 分层架构的分类

  • 严格分层架构(Strict Layers Architecture)

某层只能与其直接下层耦合，即我的奴隶的奴隶，不是我的奴隶。

  • 松散分层架构(Relaxed Layers Architecture)

允许任意上层与任意下层耦合。由于用户接口层和应用服务通常需要与基础设施打交道，许多系统都是该架构。

较低层有时也可与较高层耦合，但只限于采用观察者 (Observer)模式或者调停者(Mediator)模式场景。较低层 绝不能直接访问 较高层。例如，在使用调停者模式时，较高层可能实现了较低层的接口，然后将实现对象作为参数传递到较低层。当较低层调用该实现时， 它并不知道实现出自何处。

1.3 分层架构演进

1.3.1 传统四层架构

图片

将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层逻辑的依赖，因为它们不属业务逻辑。将一个夏杂的系统分为不同的层，每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。

传统分层架构的 基础设施层 位于底层，持久化和消息机制便位于该层。这里的消息包含MQ消息、SMTP或文本消息(SMS)。可将基础设施层中所有组件看作应用程序的低层服务，较高层与该层发生耦合以复用技术基础设施。即便如此，依然应避免核心的领域模型对象与基础设施层直接耦合。

1.3.2 改良版四层架构

传统架构的缺陷

DDD初创开发团队发现，将基础设施层放在最底层存在缺点。比如此时领域层中的一些技术实现令人头疼：

  • 违背分层架构的基本原则

  • 难以编写测试用例

何解？

使用 依赖反转设计原则 ：低层服务（如基础设施层）应依赖高层组件（比如用户界面层、应用层和领域层）所提供接口。

应用依赖反转原则

  • 依赖反转原则后的分层方式：基础设施层在最上方，可实现所有其他层中定义的接口

图片
依赖反转原则真的可以支持所有层吗？

有人认为依赖反转原则中只存在两层：最上方和最下方，上层实现下层定义的抽象接口。因此上图的基础设施层将位于最上方，而用户接口层、应用层和领域层应作 同层且都位于下方 。对此大家可保留自己意见。在六边形［Cockburn］或端口和适配器架构中对此做详细讲解。

2 各层职责

2.1 用户接口层

一般包括用户接口、Web 服务等。

只处理用户显示和用户请求，不应包含领域或业务逻辑。有人可能认为，既然用户接口需验证用户输入，那就应该包含业务逻辑。事实上，用户接口所进行的验证和对领域模型的验证不同：对那些粗制滥造且只面向领域模型的验证行为，应该予以限制。

如果用户接口使用了领域模型中的对象，那么此时领域对象仅限于数据渲染展现。在采用这种方式时，可使用展现模型对用户接口与领域对象进行解耦。由于用户可能是人，也可能是其他系统，有时用户接口层将采用开放主机服务的方式向外提供API。用户接口层是应用层的直接用户。

用户接口层很重要，在于前后端调用的适配。若你的微服务要面向很多应用或渠道提供服务，而每个渠道的入参出参都不一样，你不太可能开发出太多应用服务，这样Facade接口就起很好的作用了，包括DO和DTO对象的组装和转换等。

2.2 应用层

主要包含应用服务，理论上不应有业务规则或逻辑，而主要是面向用例和流程相关的操作。

  • 应用层位于领域层之上，因为领域层包含多个聚合，所以它可协调 多个聚合服务和领域对象完成服务编排和组合 ，协作完成业务。

  • 应用层也是微服务间的交互通道，它可调用其它微服务，完成 微服务间的服务组合和编排 。

开发设计时，不要将本该放在领域层的业务逻辑放到应用层。因为庞大的应用层会使领域模型失焦，时间一长微服务就会演化为传统MVC三层架构，导致业务逻辑混乱。

应用服务是在应用层，负责服务的组合、编排、转发、转换和传递，处理业务用例的执行顺序以及结果的拼装，以粗粒度服务通过API网关发布到前端。还可进行安全认证、权限校验、事务控制、发送或订阅领域事件等。

2.3 领域层

主要包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。

实现核心业务逻辑，通过各种校验保证业务正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

领域模型的业务逻辑主要由实体和领域服务实现：

  • 实体采用充血模型 实现所有与之相关的业务功能。

实体和领域服务在实现业务逻辑上不是同级，当领域中的某些功能，单一实体或值对象无法实现，就会用到领域服务，它可组合聚合内的多个实体或值对象，实现复杂业务逻辑。

2.4 基础层

为其它各层提供通用的技术基础服务，包含三方工具、驱动、MQ、API网关、文件、缓存、DB、基础服务等。最常用的还是提供DB持久化。

基础层包含基础服务，它采用依赖反转，封装基础资源服务，实现应用层、领域层与基础层解耦。

传统架构由于上层应用对DB强耦合，很多公司在架构演进最怕换DB，一旦更换，可能需重写一堆代码。但采用依赖反转，应用层即可通过解耦保持独立核心业务逻辑。当DB变更，只需更换DB基础服务。

3 微服务架构演进

领域模型中对象的层次从内到外依次是：值对象、实体、聚合和限界上下文。

实体或值对象的简单变更，一般不会让领域模型和微服务发生大变。但聚合的重组或拆分却可以。因为聚合内业务功能内聚，能独立完成特定业务。那聚合的重组或拆分，势必引起业务模块和系统功能变化。

可以聚合为基础单元，完成领域模型和微服务架构的演进。聚合可作为整体，在不同领域模型间重组或拆分，或直接将一个聚合独立为微服务。

微服务架构的演进案例

现有 微服务 1：包含聚合 a、b、c 微服务2：微服务3：包含聚合 d、e、f

  • 当发现微服务1中聚合a的功能经常被高频访问，以致拖累了整个微服务1的性能，可把聚合a，从微服务1中剥离，独立为微服务2以应对高性能场景

  • 随业务发展，发现微服务3的领域模型变化，聚合d会更适合放到微服务1的领域模型。即可将聚合d整体迁移到微服务1。注意定义好聚合间的代码边界

  • 架构演进后，微服务1从最初包含聚合a、b、c，演进为包含聚合b、c、d的新领域模型和微服务

可见，好的聚合和代码模型的边界设计，可让你快速应对业务变化，轻松实现领域模型和微服务架构演进。

微服务内服务的演进

在微服务内部，实体的方法被领域服务组合和封装，领域服务又被应用服务组合和封装。在服务逐层组合和封装的过程中，你会发现这样一个有趣的现象。

在服务设计时，你并不一定能完整预测有哪些下层服务会被多少个上层服务组装，因此领域层通常只提供一些原子服务，比如领域服务a、b、c。但随着系统功能增强和外部接入越来越多，应用服务会不断丰富。有一天你会发现领域服务b和c同时多次被多个应用服务调用了，执行顺序也基本一致。这时你可以考虑将b和c合并，再将应用服务中b、c的功能下沉到领域层，演进为新的领域服务（b+c）。这样既减少了服务的数量，也减轻了上层服务组合和编排的复杂度。

你看，这就是服务演进的过程，它是随着你的系统发展的，最后你会发现你的领域模型会越来越精炼，越来越能适应需求的快速变化。

三层架构如何演进到DDD分层架构？

由于层间松耦合，我们可以专注于本层的设计，而不必关心其它层，也不必担心自己的设计会影响其它层。可以说，DDD成功地降低了层与层之间的依赖。

其次，分层架构使得程序结构变得清晰，升级和维护更加容易。我们修改某层代码时，只要本层的接口参数不变，其它层可以不必修改。即使本层的接口发生变化，也只影响相邻的上层，修改工作量小且错误可以控制，不会带来意外的风险。

那我们该怎样转向DDD分层架构呢？不妨看看下面这个过程。

传统企业应用大多是单体架构，而单体架构则大多是三层架构。三层架构解决了程序内代码间调用复杂、代码职责不清的问题，但这种分层是逻辑概念，在物理上它是中心化的集中式架构，并不适合分布式微服务架构。

DDD分层架构中的要素其实和三层架构类似，只是在DDD分层架构中，这些要素被重新归类，重新划分了层，确定了层与层之间的交互规则和职责边界。

三层架构向DDD分层架构演进，主要发生在业务逻辑层和数据访问层。

DDD分层架构在用户接口层引入了DTO，给前端提供了更多的可使用数据和更高的展示灵活性。

DDD分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。DDD分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。

另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用DAO方式；DDD分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。

关于仓储。仓储本身属于基础层，但考虑到一个聚合对应一个仓储，为了以后聚合代码整体迁移方便，在微服务代码目录设计时，在聚合目录下增加一个Repository的仓储目录，跟仓储相关的代码都在这个目录下。

这个目录下的代码与聚合的其它业务代码是分开的。如果未来换数据库，只需将Repository目录下的代码替换。而如果聚合需要整体迁移到其它微服务中去，仓储的代码也会一并迁移。

仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config等通用的公共的资源类统一放到了基础层。

总结

DDD分层架构包含用户接口层、应用层、领域层和基础层。通过这些层次划分，我们可以明确微服务各层的职能，划定各领域对象的边界，确定各领域对象的协作方式。

-End-

最近有一些小伙伴，让我帮忙找一些 面试题 资料，于是我翻遍了收藏的 5T 资料后，汇总整理出来，可以说是程序员面试必备！所有资料都整理到网盘了，欢迎下载！

点击????卡片，关注后回复【面试题】即可获取

在看点这里好文分享给更多人↓↓

以上是关于DDD领域驱动设计实战-分层架构及代码目录结构的主要内容，如果未能解决你的问题，请参考以下文章

DDD领域驱动设计：四层架构应用

DDD领域驱动设计：四层架构应用

DDD 领域驱动设计落地实践系列：工程结构分层设计

DDD-领域驱动设计重构的痛点及项目结构的划分

领域驱动设计 领域事件DDD分层架构

解构领域驱动设计：领域驱动设计的核心之分层架构