文章总结： DDD是一种以领域为核心的软件开发方法论，通过建立领域模型和分层架构来构建符合业务的高质量系统。核心概念包括领域、子域、限界上下文、实体、值对象、聚合等，采用四层架构（用户接口层、应用层、领域层、基础设施层）并保持单向依赖关系。设计流程包括理解业务、划分领域、定义限界上下文、构建领域模型和分层实现，可有效提高代码可维护性和可扩展性。
综合评分： 85
文章分类： 安全建设,解决方案,技术标准

DDD架构设计思想

原创

静观云起

静观云起

2025年11月25日 18:01
广东

一 什么是DDD

DDD(Domain-Driven Design，领域驱动设计)是由 Eric Evans 在 2004 年提出的一种软件开发方法论与架构思想，核心是以领域为核心驱动力，通过深入理解业务，建立领域模型，并围绕领域模型来组织代码与系统架构，从而构建符合业务、可维护、可扩展的高质量软件系统。

二 为什么要用DDD

传统开发(如 CRUD 系统)往往：

• 业务逻辑分散，代码与业务脱节
• 随着业务复杂度上升，系统难以维护和演进
• 开发人员不懂业务，业务人员不懂代码

DDD 的价值在于：

✅ 让技术与业务深度融合

✅ 通过领域模型明确表达业务规则与核心逻辑

✅ 有效应对复杂业务系统的设计与演化

✅ 提高代码的可维护性、可读性与可扩展性

三 DDD核心概念

| | |
| — | — |
| 概念 | 说明 |
| 领域(Domain) | 业务所涉及的范畴,比如电商,金融,物流等 |
| 子域(Subdomain) | 领域的细分，比如电商中的订单域、商品域、用户域 |
| 核心域(Core Domain) | 企业的核心竞争力所在，优先投入资源 |
| 支撑域(Supporting Domain) | 支持核心业务的辅助功能，如日志、权限 |
| 通用域(Generic Domain) | 通用功能，如工具、基础服务，可复用 |
| 限界上下文(Bounded Context) | 领域模型的边界，每个上下文中领域模型具有明确含义，避免概念混淆 |
| 领域模型(Domain Model) | 对业务问题进行抽象得到的概念模型，包含实体、值对象、聚合等 |
| 实体(Entity) | 有唯一标识，在生命周期中可变化，比如用户、订单 |
| 值对象(Value Object) | 没有唯一标识，通过属性定义，不可变，比如地址、金额 |
| 聚合(Aggregate) | 一组相关对象的集合，对外作为一个整体，有一个根实体(聚合根) |
| 聚合根(Aggregate Root) | 聚合的入口，外部只能通过它来访问聚合内部对象 |
| 领域服务(Domain Service) | 处理不适合放在实体/值对象中的业务逻辑 |
| 仓储(Repository) | 负责领域对象的存储与查询，是对数据库等持久层的抽象 |
| 领域事件(Domain Event) | 领域中发生的重要事情，可用于解耦与异步处理 |

四 DDD分层架构

DDD 推荐采用 分层架构，将系统按照职责划分为多个层次，每层有明确的职责与依赖方向，典型为四层架构：

1.用户接口层（Interface / Presentation Layer）

职责：接收用户输入，返回展示数据

包括：Controller、REST API、GraphQL、UI 等

✅只负责请求转发与响应格式化，不包含业务逻辑

2.应用层（Application Layer）

职责：编排业务用例，协调领域对象完成任务

包括：用例(Use Case)、应用服务(Application Service)

✅不包含核心业务规则，而是调用领域层完成操作**

✅可包含事务控制、权限校验、请求校验等**

3.领域层（Domain Layer）【核心】

职责：承载核心业务逻辑与规则

包括：实体(Entity)、值对象(Value Object)、聚合(Aggregate)、领域服务(Domain Service)、仓储接口(Repository Interface)、领域事件

✅这是 DDD 的核心层，包含最多的业务知识与模型**

4.基础设施层（Infrastructure Layer）

职责：提供通用技术能力支撑，如数据库访问、消息队列、缓存、外部接口调用等

包括：仓储实现(Repository Impl)、ORM 框架、工具类、第三方服务集成

✅为上层提供支持，不包含业务逻辑**

五 DDD架构分层依赖关系

依赖方向是 由上至下，单向依赖

✅用户接口层只做请求/响应处理

✅应用层协调领域对象，组织用例流程

✅领域层是核心，不依赖任何其他层

✅基础设施层实现领域层定义的接口(如 Repository 接口)

这种分层与依赖关系保证了业务逻辑的内聚与清晰，避免技术污染业务

六 DDD设计流程

1. 理解业务，划分领域与子域

✅与业务专家沟通，明确业务边界与核心问题

✅识别核心域、支撑域、通用域

2. 定义限界上下文(Bounded Context)

✅明确每个模型的适用范围，避免一词多义

✅每个限界上下文可视为一个微服务或模块

3. 构建领域模型

✅识别实体、值对象、聚合、聚合根

✅定义领域服务、领域事件

✅建立统一语言(Ubiquitous Language),团队共用一套业务术语

4. 分层实现

✅按 DDD 分层架构组织代码：接口层、应用层、领域层、基础设施层

✅领域层只包含业务逻辑，基础设施层提供技术实现

5. 持续演进

✅业务变化时，领域模型可演进，保持核心稳定

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：静观云起 静观云起《DDD架构设计思想》