DDD 架构之领域驱动设计【通俗易懂】

1. 前言

官方回答：DDD是一种应对复杂业务系统的设计方法，通过将软件设计与业务领域紧密结合，帮助开发人员构建清晰、可维护的领域模型。在复杂的业务系统中，它能显著提升软件设计的质量和可维护性。

说人话：传统的 MVC 三层架构业务混杂，耦合度太高，，N 年后…，这谁写的？绝对不是我，前人挖坑后人填坑，根本无从下手！

于是出现了 DDD 四层架构，简而言之，更抽象啦！

遵循三大原则：单一职责原则、开放封闭原则和依赖倒转原则。一个类只负责一项功能，对外开放扩展，对内不允许修改，并且要依赖接口开发，而非具体的实现类。

核心概念：
领域（Domain）：软件要解决的业务问题。
限界上下文（Bounded Context）：业务中的一个独立模块，比如“订单管理”或“用户管理”。
实体（Entity）：有唯一标识的对象，比如“用户”。
值对象（Value Object）：没有唯一标识的对象，比如“地址”。
聚合（Aggregate）：一组相关对象的集合，比如“订单”和“订单项”。
领域服务（Domain Service）：处理跨多个对象的业务逻辑。
仓储（Repository）：用来存取聚合的接口。

DDD 特点：
① 业务优先技术，以领域划分为设计基础；
② DDD 以通用语言为建设核心，每个领域内有相同的包结构；
③ 以一系列抽象概念为开发模式；
④ 以四层架构为基本思想；
⑤ 有助于解决系统老化的问题。

2. MVC 对比 DDD

① 传统 MVC 是三层架构：控制层、业务层、基础层。技术优先，所有业务都混在一起：

MVC 架构存在的问题：
① 可维护性差，大量的第三方模块影响核心代码的稳定性；
② 可扩展性差，业务逻辑与数据存储相互依赖，无法复用；
③ 可测试性差，庞大事务脚本与基础设施强耦合，无法进行单元测试。

如何构建高质量应用？高内聚，低耦合！

② DDD 是四层架构：用户接口层、应用层、领域层、基础层。业务优先，以业务领域来划分模块：

3. DDD 分层架构

用户接口层：负责展示和交互，通常包括Web界面、API接口等。
应用层：协调领域层和外部系统，应用层不包含业务逻辑，主要调用领域服务。
领域层：核心业务逻辑，包括实体、值对象、聚合、领域服务等。
基础设施层：提供技术实现，如数据库访问、消息队列、外部API调用等。

核心的业务逻辑全部放在领域层，其余层都可以看作是转发站！

目录结构如下：

4. 完整业务流程

第一步，前端发起 HTTP 请求 ☞

第二步，请求进入用户接口层的 OrderController 中 ☞

第三步，OrderController 调用应用层的 OrderAppService ☞

第四步，OrderAppService 又调用了领域层的 OrderService ☞

第五步，OrderService 调用了仓储接口 OrderRepository ☞

第六步，由基础层的 OrderRepositoryImpl 处理具体的数据库关系。

如果业务简单，OrderAppService 可直接调用 OrderRepository！