Java知识体系

Appearance

什么是 DDD领域驱动设计

一、基本介绍 ​

DDD（Domain-Driven Design，领域驱动设计）是一种软件设计方法，它强调以业务领域为核心来构建复杂的软件系统。DDD 的核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。这种方法特别适用于处理复杂的业务需求和业务逻辑。

DDD 与 MVC（Model-View-Controller，模型-视图-控制器）开发模式相比，DDD 是领域驱动，自顶向下的设计方法，关注业务活动，而 MVC 是数据驱动，自低向上的思想，关注数据。DDD 的设计方式可以让领域划分更加清楚，利于扩展和维护，实现高度自治和高度内聚，即高内聚、低耦合。

在 MVC 的开发模式中，模型（Model）负责数据的处理和业务逻辑，视图（View）负责展示数据给用户，并处理用户的输入，控制器（Controller）负责协调模型和视图之间的交互。而 DDD 的分层架构通常包括用户接口层、应用层、领域层和基础层。各层之间职责明确，相互独立，通过接口进行交互。

DDD 的分层架构设计包括：

  1. 用户接口层：负责向用户展示信息和接收用户指令。
  2. 应用层：作为业务用例的协调者，负责处理用户请求，调用领域层进行业务处理，并返回处理结果。
  3. 领域层：包含领域模型和业务逻辑，是系统的核心部分。
  4. 基础层：提供基础设施服务，如数据库访问、消息队列、缓存等。

DDD 的优势在于它能够接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD 让你首先考虑的是业务语言，而不是数据。它强调业务抽象和面向对象编程，而不是过程式业务逻辑实现。

DDD 是设计一个高质量软件系统中的一种解决方案，它通过领域建模、限界上下文、统一语言等技术手段，帮助开发者更好地理解和处理复杂的业务逻辑，从而构建出可维护、可扩展的软件系统。

二、DDD 架构 ​

改良版四层架构 ​

DDD（领域驱动设计）的四层架构是一种常见的架构模式，用于构建复杂的业务系统。这种架构模式将系统分为四个层次，每一层都有其特定的职责和功能。

image.png

（1）用户接口层（Presentation Layer） ​
  • 职责：这是系统的最外层，直接与用户或其他系统交互。它负责接收输入请求并返回响应结果。
  • 特点：
    • 提供必要的参数校验和异常捕获流程。
    • 通常很薄，不包含复杂的业务逻辑。
    • 负责VO（Value Object）或DTO（Data Transfer Object）到Entity的转换，用于适配前后端调用。
    • 对外暴露API，形式不限于RPC、REST API、消息等。
（2）应用层（Application Layer） ​
  • 职责：应用层是业务用例的协调者，它定义了系统的操作，如创建订单、查询用户等。
  • 特点：
    • 不处理业务逻辑，而是调用领域层的服务。
    • 负责服务编排，如权限校验、事务控制等。
    • 可以发布或订阅领域事件。
    • 通常包含用例级别的方法，执行轻量级逻辑。
（3）领域层（Domain Layer） ​
  • 职责：领域层是系统的核心，包含了业务逻辑和业务规则。
  • 特点：
    • 包含实体（Entity）和值对象（Value Object），使用充血模型实现业务功能。
    • 业务逻辑封装在聚合根中，对外提供领域级别的服务接口。
    • 聚合根之间通过ID引用，不能直接操作其他聚合根。
    • 领域服务用于跨实体的状态变化，但不能直接修改实体状态，只能调用实体的业务方法。
（4）基础设施层（Infrastructure Layer） ​
  • 职责：基础设施层为业务逻辑提供支撑，包括技术实现和第三方服务的集成。
  • 特点：
    • 提供通用技术能力，如数据库交互、缓存、消息队列等。
    • 实现防腐层，用于业务检查和隔离第三方服务。
    • 包含仓储层接口，但聚合根才拥有Repository，Repository不同于DAO，它向领域模型提供聚合根。
依赖倒置原则 ​

在DDD架构中，依赖倒置原则是关键，它要求低层服务（如基础设施层）依赖于高层组件（如应用层、领域层）所提供的接口。这样可以实现各层之间的解耦，提高系统的灵活性和可测试性。

  • 具体依赖于抽象：高层组件定义接口，低层组件实现这些接口。
  • 抽象依赖于具体：高层组件不依赖于低层组件的具体实现，而是依赖于它们提供的抽象接口。

通过这种架构和设计原则，DDD有助于构建可维护、可扩展的复杂业务系统。它将业务逻辑集中在领域层，通过应用层协调不同的业务用例，用户接口层处理外部请求，基础设施层提供技术支持，从而实现了清晰的分层和职责划分。

整洁架构(洋葱架构) ​

整洁架构（也称为洋葱架构）是一种软件架构模式，它的目的是清晰地分离系统中的不同职责，使得系统更容易理解和维护。整洁架构通过一系列的同心圆来表示软件的不同层次，每个层次都有其特定的职责和功能。

image.png|600

整洁架构的层次：

  1. 领域模型（Domain Model）：
    • 位于架构的中心，封装了企业级的业务规则。
    • 主体是实体（Entity），可以是带方法的对象，也可以是数据结构和方法的集合。
    • 实现领域内核心业务逻辑。
  2. 领域服务（Domain Services）：
    • 位于领域模型和应用服务之间，实现涉及多个实体的复杂业务逻辑。
    • 领域服务用于协调领域模型中的实体，处理跨实体的业务操作。
  3. 应用服务（Application Services）：
    • 定义系统的操作，如创建订单、查询用户等。
    • 实现与用户操作相关的服务组合与编排。
    • 包含应用特有的业务流程规则，封装和实现了系统所有用例。
  4. 最外层（User Interface / Infrastructure）：
    • 提供适配的能力，分为主动适配和被动适配。
    • 主动适配：实现外部用户、网页、批处理和自动化测试等对内层业务逻辑的访问适配。
    • 被动适配：实现核心业务逻辑对基础资源访问的适配，如数据库、缓存、文件系统和消息中间件等。

整洁架构的原则：

  • 依赖原则：整洁架构的最核心原则是依赖原则，也称为“好莱坞原则”（Don't call us, we'll call you）。
    • 外层代码依赖只能指向内层，内层不需要知道外层的任何情况。
    • 越往里依赖越低，代码级别越高，越是核心能力。

整洁架构的优点：

  • 清晰的职责划分：每个层次都有明确的职责，使得代码更加模块化。
  • 易于测试：由于层次分明，可以更容易地对内部层次进行单元测试，而不需要模拟外部层次。
  • 灵活性：外部层次的变化不会影响到内部层次，使得系统更容易适应变化。

整洁架构的实现：

  • 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
  • 这种架构模式强调核心业务逻辑与外部变化的解耦，使得系统的核心部分更加稳定和可靠。

整洁架构（洋葱架构）通过这种层次分明的结构，帮助开发者构建出高内聚低耦合的系统，从而提高软件的可维护性和可扩展性。

CQRS架构(命令查询隔离架构) ​

CQRS（Command Query Responsibility Segregation，命令查询责任隔离）架构是一种软件设计模式，它将系统中的读（查询）和写（命令）操作分离开来，以提高性能和可伸缩性。这种模式特别适用于读操作和写操作有显著不同需求的场景。

CQRS的基本概念：

  • Command（命令）：指的是引起数据变化的操作，如新增、更新、删除等。
  • Query（查询）：指的是不会引起数据变化的操作，只是按条件查找数据。

CQRS的三种模式：

image.png

  1. 共享模型/共享存储：
    • 读写操作使用同一种领域模型。
    • 读写模型共享同一种数据存储。
  2. 分离模型/共享存储：
    • 读操作使用读领域模型，写操作使用写领域模型。
    • 读写模型不同，但共享同一种数据存储。
  3. 分离模型/分离存储：
    • 也称为事件源（Event Sourcing）CQRS。
    • 使用领域事件来保证读写数据的一致性。
    • 当命令系统完成数据更新后，通过领域事件通知查询系统，查询系统接收事件后更新自己的数据源。

CQRS架构的优势：

  • 性能优化：读操作和写操作可以针对各自的需求进行优化。
  • 可伸缩性：可以根据负载分别扩展读和写的能力。
  • 灵活性：可以根据不同的业务需求定制读和写模型。

CQRS在DDD（领域驱动设计）中的应用：

在DDD中，写操作通常遵循“应用服务 -> 聚合根 -> 资源库”的结构，而读操作可能不需要完全遵循这一结构。CQRS允许我们根据读操作的需求设计不同的读模型和读仓库，从而提高查询性能。

CQRS实战中的应用：

  • 读操作：

    • 基于数据模型，应用层提供单独的读仓库。
    • 绕过聚合根和资源库，直接在应用层返回数据。
    • 专注于快速返回数据，提高查询性能。

  • 写操作：

    • 基于领域模型，通过“应用服务 -> 聚合根/领域服务 -> 资源库”的结构进行编码。
    • 专注于业务逻辑和数据一致性。

CQRS架构通过分离读和写操作，允许系统针对不同的操作需求进行优化。在DDD中，这种分离使得我们可以为读操作和写操作设计不同的模型和存储，从而提高系统的性能和可伸缩性。通过事件源CQRS，我们可以使用领域事件来同步读写操作，确保数据的一致性。这种架构特别适合于读多写少或读写负载差异较大的系统。

六边形架构(端口适配器架构) ​

六边形架构（也称为端口-适配器架构）是一种软件架构模式，它的核心理念是应用程序通过端口与外部进行交互。这种架构模式旨在解耦内部业务逻辑与外部资源，包括用户界面、数据库、第三方服务等。

六边形架构的核心特点：

  • 核心业务逻辑：位于内部六边形，与外部资源完全隔离。
  • 适配器：作为内部业务逻辑与外部资源之间的桥梁，实现协议转换。
  • 端口：定义了与外部系统交互的接口。

六边形架构的层次划分：

  1. 内六边形（Core）：

    • 包含应用程序的核心业务逻辑和领域模型。
    • 不依赖于任何外部系统的具体实现。

  2. 外六边形（Infrastructure and User Interface）：

    • 处理外部应用、驱动和基础资源的交互和访问。
    • 对前端应用以API主动适配的方式提供服务。
    • 对基础资源以依赖倒置被动适配的方式实现资源访问。

六边形架构的核心理念是：应用是通过端口与外部进行交互的

六边形架构通过将系统分为内六边形和外六边形两层，实现了核心业务逻辑与外部资源的解耦。这种架构模式强调了端口和适配器的重要性，使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。六边形架构是实现高内聚低耦合系统的有效方法，特别适用于需要与多种外部系统交互的复杂应用程序。

下图的红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。

image.png|600

六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分如下：红圈内的六边形实现应用的核心业务逻辑；外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用

总结 ​

image.png 这三种架构模型的设计思想微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想，将核心业务逻辑与外部应用、基础资源进行隔离。

红色框内部主要实现核心业务逻辑，但核心业务逻辑也是有差异的，有的业务逻辑属于领域模型的能力，有的则属于面向用户的用例和流程编排能力。按照这种功能的差异，我们在这三种架构中划分了应用层和领域层，来承担不同的业务逻辑。 领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。 应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。

参考链接: https://blog.csdn.net/qq_41889508/article/details/124907312