DDD浅析

最新推荐文章于 2025-08-15 00:03:14 发布
原创 最新推荐文章于 2025-08-15 00:03:14 发布 · 920 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#DDD #架构设计

DDD（Domain Driven Design）在04年由著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名：领域驱动设计—软件核心复杂性应对之道)一书中提出了“领域驱动设计(简称 ddd)”的概念，但是这么多年一直不温不火，最近几年为什么又开始火起来了呢？这里就要从历史上的软件危机开始说起。

历史软件危机

下图是从60年代至今的出现软件危机。
在这里插入图片描述

第一次软件危机

60年代之前一直是汇编语言的天下，但是我们都知道汇编语言写起来巨慢无比，很难工业化，所以在60-70年代，面向过程语言出现来解决了这个问题，比如最经典的C语言，现在很多操作系统还是用C语言来编写。

第二次软件危机

80年代后，随着硬件的发展和面向过程语言出现后，大型软件也应用而生，但是面向过程型语言在大型软件上是很难维护的，比如我们知道的Java的JVM，就用C++来编写的，这个时候面向对象语言和设计模式的诞生解决这个问题。

第三次软件危机

2000之后，互联网热潮到来，需求的多样化，对三高场景的要求下，面向对象型语言和设计模式也无法解决这个痛点，这个时候，微服务到来解决这个问题，目前我们知道，90%的互联网企业都是微服务。

第四次软件危机

2015年之后，互联网热潮退化，回归到需求本身，而需求本身的变化越来越快，“小步快跑，快速迭代试错”的敏捷迭代下，系统越来越难维护，每个公司发展的一定阶段都会遇到这个问题，那么是什么来解决这个问题呢？有人说是DDD，我们接下来分析一下DDD到底能否解决这个问题。

问题和痛点

服务或者系统大多数的坏味道都有以下几点:

  • 一个字段变化导致从Mapper改到Controller
  • 一个商品需求的变化导致订单、结算等都要跟着变化
  • 基础域的一个模型的变化导致商品、订单、结算都要改造
  • 订单表字段很多，修改评价的逻辑却影响了订单的核心逻辑
  • …

归根就地的原因是过度耦合。

出现这些问题的本质原因

很多系统出现上面的问题无外乎下面几个原因:

  • 小步快跑，快速迭代试错
  • 业务日益复杂，需求迅速变化
  • 贫血模型导致逻辑分散到很多地方
  • 设计阶段总是考虑存储
  • 小范围重构
  • 技术能力参差不齐
  • …

那么，这些问题的本质原因是什么呢？实际上就是领域划分不清晰，如果我们的领域足够清晰，各司其职，高内聚低耦合，那么上面的这些原因是无法导致我们的系统逐渐变的难以维护的。

DDD是否能解决这个问题

我们先不着急说结论，先看一下DDD的过程。
在这里插入图片描述
DDD的过程大概分成五步:

  1. PM、RD、CTO根据业务需求划分出初步的领域和限界上下文，以及上下文之间的关系，这里的CTO的角色就是我们常说的领域专家。
  2. 根据分析出的限界上下文来进行子域划分。
  3. 事件风暴进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；
  4. 为聚合根设计仓储，并思考实体或值对象的创建方式；
  5. 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并进行重构。

这个过程，第一、二步是战略设计，后面三步就是落地的战术设计。

战略设计-限界上下文关系设计

下图是一个普通电商平台的领域上下文设计。
在这里插入图片描述

战略设计-子域划分

在这里插入图片描述

战术设计-事件风暴的过程

在这里插入图片描述
不同的聚合直接交互是通过聚合根中来交互，传入的数据是值对象，最终达到的效果是收敛变化，暴露不变。

术语

到这里，我们看出DDD的一些术语。

术语含义
领域领域是一个组织所做的事情以及其中包括的一切，比如电商平台
子域当一个领域非常大时理解子域的概念，必须和核心域对应起来，子域也是领域的一部分，只不过它的重要性没有核心域那么大，它们之间的关系，你可以看作是人体器官中，心脏和其他器官的关系，在《领域驱动设计》中，其实并没有子域的概念，而是通用子域（Common Subdomain），而在《实现领域驱动设计》中，作者把子域拆分成了支撑子域（Generic Subdomain）和通用子域（Common Subdomain）
通用子域变化比较小，通用性很强的领域，在整个业务下使用比如商品领域，在一个领域下，用户是很少变化的
支撑子域变化比较小，只在某一些场景下会使用，比如用户领域
核心子域变化比较大，只在某一些场景下会使用，比如订单领域
聚合聚合是多个模型单元间的组合，它定义了模型的关系和边界，它有聚合根、实体、值对象组成，比如订单就是一个聚合
聚合根访问聚合的唯一凭证，一般是业务编号，比如订单的订单号
实体实体与面向对象中的概念类似，在这里再次提出是因为它是领域模型的基本元素。在领域模型中，实体应该具有唯一的标识符，从设计的一开始就应该考虑实体，决定是否建立一个实体也是十分重要的。
值对象值对象和我们说的编程中数值类型的变量是不同的，它仅仅是没有唯一标识符的实体，比如有两个收获地址的信息完全一样，那它就是值对象，并不是实体。值对象在领域模型中是可以被共享的，他们应该是“不可变的”（只读的），当有其他地方需要用到值对象时，可以将它的副本作为参数传递。
领域服务一个领域的接口服务，不是指一个微服务，是指一个微服务的接口
领域事件事件消息发出的领域对象
防腐层防腐层在DDD里是很重要的，服务内部是否变坏，很大一部分的功劳是防腐层赋予的。

战术设计-服务落地

在这里插入图片描述

DDD防腐层的转换器设计

详看: https://blog.csdn.net/feigeswjtu/article/details/122562207

DDD的本质

DDD的设计写完了，那么我们再回过来看它的本质是什么呢？一个词: “以不变应万变”，不变是领域对外封装变化，对内允许变化。

【DDD】学习笔记-需求分析
xqdd的专栏
02-03 1201
DDD项目先期的需求分析
DDD与微服务架构浅析
JavaGPT的博客
04-30 913
代码精选（www.codehuber.com），程序员的终身学习网站已上线！后端技术】、【前端领域】感兴趣的小可爱，也欢迎关注❤️❤️❤️ 【JavaGPT】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】💝💝💝！
DDD 实战 (3)：整体工作框架和全局需求分析
hangsun的博客
03-11 5310
DDD 本质上是个“软件设计”方法论，它指导的是“怎么做软件设计”。故在正式开始“群买菜”的软件设计之前，我们先对 DDD 整体方法论做一个简单的、从我个人角度理解的介绍。
DDD浅析项目数据流
cpxsxn的博客
04-11 1448
DDD（领域驱动设计）总体结构分为四层: Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces(表示层，也叫用户界面层或是接口层)， 各个层面的作用下面介绍： 用户界面（表现层）：负责给用户展示信息，并解释用户命令。 应用层：该层协调应用程序的活动。不包括任何业务逻辑，不保存业务对象的状态，但能保存应用程序任务过程的状态。3. 领域层：这一层包括业务领域的信息。业务对象的状态在这里保存。业务对象的持久化和它们的状态可能会委托给基础设施层
进阶篇：DDD 架构模式：原理、实战、防腐策略及优劣势分析
最新发布
u014730578的博客
08-15 658
DDD 提供了处理复杂业务系统的系统化方法论，通过聚合、领域服务、限界上下文及防腐层实现业务逻辑集中管理和外部系统隔离。虽然初期学习成本高、开发复杂，但对中大型系统，DDD 能带来高可维护性、高可扩展性和业务一致性。
DDD分析
kobexzf的博客
07-24 418
而基于充血模型（RichDomainModel）DDD正好相反，数据和对应的业务逻辑被封装到同一个类中。因此，这种充血模型满足面向对象的封装特性，是典型的面向对象编程风格。传统的mvc框架的开发，因为po对象只包含属性和setter、getter，不包含业务逻辑，叫做贫血模式；这种写法实际上并不符合面向对象的特性，实际是面向过程的写法。...
DDD领域分析
Mario_z的博客
11-07 545
DDD领域分析
DDD思想 - Domain Driven Design
weixin_33347188的博客
07-26 757
主要是围绕用户、角色和两者的关系，构建权限分配领域模型。采用 DDD 4 层架构，包括用户接口层、应用层、领域层和基础服务层。数据通过 VO、DTO、DO、PO 转换，进行分层隔离。采用 SpringBoot + MyBatis Plus 框架，存储用 MySQL。谈谈我对 DDD 的理解，我觉得 DDD 不像一门技术，我理解的技术比如高并发、缓存、消息队列等，DDD 更像是一项软技能，一种方法论，包含了很多设计理念。
浅析.NET逻辑分层架构
10-23
DDD分层架构的核心是将业务逻辑层进一步细分为应用层（服务层）和领域层（领域逻辑层），并将数据访问和其他具体技术实现统一到基础设施层中。这种设计模式能够帮助开发团队更清晰地管理业务逻辑，并且能够减少层间...
架构设计基础系列：架构4+1视图模型浅析
沛哥儿的专栏
04-01 1291
在场景视图中，用户下单需同时涉及逻辑视图的领域模型、过程视图的消息队列、物理视图的 Pod 部署。（注：此处为 Kubernetes 集群部署图，展示 Pod、Service、Ingress 的分布）‌ 描述复杂系统的架构，满足不同利益相关者（开发者、运维、业务方等）的关注点。例如：逻辑视图中的订单服务类，在过程视图中通过 HTTP 接口与支付服务交互。模块化设计（逻辑视图）与清晰的部署规范（物理视图）便于后续扩展和迭代。‌：根据项目规模调整视图颗粒度（如小型系统可合并逻辑视图与开发视图）；
使用DDD分析和设计微服务
锐意工作室
06-13 366
文章目录使用DDD分析和设计微服务前言为什么使用DDD分析和设计微服务使用DDD分析和设计微服务参考文档 使用DDD分析和设计微服务 前言 本文描述了如何通过DDD和Event Storming来分析和设计微服务。 为什么使用DDD分析和设计微服务 使用DDD分析和设计微服务的好处主要包括： 微服务边界划分更合理 微服务粒度更合适 微服务间的调用关系更清晰 避免事务一致性的问题 更好地为微服务建模（更加准确地描述业务领域） 加深对业务领域的理解，促进技术专家和业务专家的协作 使用DDD分析和设计微服务
领域驱动设计 (DDD)实例分析
热门推荐
wh柒八九的博客
08-21 1万+
本文结合实例来分析下领域驱动设计 (DDD) 文章目录概述 概述
采用DDD理论分析项目管理全过程
转错的弯，走错的路
03-19 872
从需求、产品线/产品、开发、测试、运维到运营，利用DDD领域驱动设计理论进行抽象细化演练全过程。 采用堆积韦恩图绘制各环节要点示例如下： 利用DDD之子域划分及限界上下文理论绘制限界上下文图谱： 最后汇总框图结构化输出示例： ...
Jdon DDD分析法
legend_x的专栏
09-07 787
我个人认为上面这张图和Jdon分析法的图比较类似：
由Spring应用的瑕疵谈谈DDD的概念与应用（二）
weixin_33953384的博客
04-14 504
在上一篇文章中，通过Spring Web应用的瑕疵引出改善的措施，我们讲解了领域驱动开发的相关概念和设计策略。本文主要讲解领域模型的几种类型和DDD的简单实践案例。 架构风格 在《实现领域驱动设计》一书中提到了几种架构风格：六边形架构、REST架构、CQRS 和事件驱动等。在实际使用中，落地的架构并非是纯粹其中的一种，而很有可能户将上述几种架构风格结合起来实现。 分层架构 分层架构的一个重要原则是...
浅析DDD(领域驱动设计)
lisheng19870305的专栏
12-20 433
最近在做一些微服务相关的设计，内容包括服务的划分，Restful API的设计等。其中比较棘手的就是Service的职责划分：如何抽象具有统一业务范畴的Model，使其模块化，又如何高度提炼并组合多模块，使得业务可独立服务化。为了找寻答案，看了不少书籍和博客，在DDD中找到了一些思路，个人觉得受益匪浅，或许也可以受用于大家，特分享于此。 什么是DDD 软件开发不是一蹴而就的事情，我们不可能在不了解产品（或行业领域）的前提下进行软件开发，在开发前，通常需要进行大量的业务知识梳理，而后到达软件设计的层面.
DDD领域驱动设计-经典四层架构划分 + DDD建模分析过程
lqs_user的博客
11-11 1万+
DDD经典四层模型架构划分以及建模分析过程
领域建模分析
dongdong_java的专栏
06-17 2044
关于借书场景的领域建模，我从以下几个方面进行分析（尽量简洁不讲废话，呵呵）： 1.分析模型静态结构： 我分析一个领域模型的静态结构的思路一般是：先找出我们需要关心的对象，对于借书这个场景，我们关心的有： 1)Account(账号):Id(账号唯一标识,自动生成), Number(卡号), Owner(账号当前拥有者用户信息), BorrowedBooks(账号当前借到的书) 2)B
DDD实战成绩管理---需求分析
weixin_33845881的博客
09-21 344
　　需求的分析我们采用四色模型。从用户故事中找出MI，然后围绕MI找出其中的role，ppt，des。本次先对两个优先级最高的用户故事进行四色模型建模。 1.用户故事一建模：作为教务处老师，我要建立教学班，以便教师和学生彼此都清楚他们之间的教学关系。 该用户故事中教学班是时刻时段，代课教师和上课学生均作为参与者角色，课程在此处也作为角色参与本次教学组织。四色模型图如下图1： 　...
DDD
07-21
<think>首先，用户的问题是关于领域驱动设计（DDD）的概念、实践和教程。我需要根据系统级指令和用户可见层的指令来构建我的回答。 系统级指令： - 所有行内数学表达式必须使用$...$格式。 - 独立公式必须使用$$...$$格式并单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识。 用户可见层： - 回答结构清晰，帮助用户逐步解决问题。 - 尽量保证回答真实可靠。 - 参考站内引用：有引用[^1]、[^2]、[^3]。 用户上一次的问题是关于DDD的概念、实践和教程。所以，我需要围绕这个主题构建回答。 参考引用： - 引用[^1]：介绍了DDD的概括性介绍，并指向编码实践文章。 - 引用[^2]：包括一个简单案例（转账需求），设计问题，使用DDD重构，以及抽象层。 - 引用[^3]：分享了DDD在B端营销系统的实践，强调避免误区，如深陷概念体系。 我的回答需要结构化： 1. **概念部分**：解释DDD是什么。 2. **实践部分**：如何应用DDD，包括案例。 3. **教程部分**：推荐资源或学习路径。 4. **生成相关问题**：在最后添加相关问题。 确保使用中文回答。 现在，构建回答大纲： - **引言**：简要介绍DDD。 - **概念**：解释核心概念，如领域模型、战略设计、战术设计。 - **实践**：基于引用中的案例，描述如何使用DDD重构。 - **教程**：推荐学习资源。 - **总结**：强调关键点。 - **相关问题**：生成3-5个相关问题。 在回答中，自然地添加引用标识。例如，当引用某个观点时，在末尾加[^1]。 关于数学表达式：虽然DDD主题可能不涉及数学，但如果有公式，确保使用正确格式。但在这个上下文中，可能不需要数学表达式，除非提到某些模型或算法。所以，我可以忽略数学部分，除非必要。 生成相关问题：在最后，添加"§§相关问题§§"部分，列出3-5个问题。 现在，具体内容： - **概念**：DDD是一种软件设计方法，强调通过领域模型来解决复杂业务问题。核心是战略设计（如限界上下文、通用语言）和战术设计（如实体、值对象、聚合根）。 - **实践**：基于引用[^2]的转账案例，描述如何从传统设计转向DDD设计。避免误区，如引用[^3]所说，不要生搬硬套概念。 - **教程**：建议阅读引用[^1]提到的编码实践文章，以及其他资源如书籍（Eric Evans的《Domain-Driven Design》）、在线课程。 确保回答真实可靠：基于提供的引用，不要编造信息。 最后，生成相关问题： 1. DDD的战略设计和战术设计有什么区别？ 2. 如何避免DDD实施中的常见误区？ 3. DDD在微服务架构中的应用是什么？ 4. 有哪些推荐的DDD学习资源？ 完整回答结构： 1. 介绍DDD。 2. 详细解释概念。 3. 分享实践案例。 4. 提供教程建议。 5. 总结。 6. 相关问题。</think>### 领域驱动设计（DDD）概念、实践与教程指南 领域驱动设计（Domain-Driven Design，DDD）是一种软件设计方法论，专注于通过构建领域模型来解决复杂业务问题。它强调开发人员与领域专家协作，使用通用语言（Ubiquitous Language）来统一业务和技术概念，从而提升软件的可维护性和扩展性。DDD 的核心包括战略设计（如限界上下文、核心域）和战术设计（如实体、值对象、聚合根），这些元素共同帮助团队在业务变化中保持系统弹性[^1]。以下我将逐步介绍 DDD 的概念、实践和教程资源，确保回答基于可靠参考和实际案例。 #### 1. **DDD 核心概念** DDD 的核心在于将软件设计与业务领域紧密结合，避免技术实现与业务需求脱节。关键概念包括： - **战略设计**：定义业务边界，如限界上下文（Bounded Context），它划分不同业务领域，防止模型污染。例如，在电商系统中，“订单”和“库存”可能属于不同限界上下文[^2]。 - **战术设计**：实现领域模型的具体元素： - **实体（Entity）**：具有唯一标识的对象（如用户ID）。 - **值对象（Value Object）**：无标识的对象，仅通过属性定义（如地址）。 - **聚合根（Aggregate Root）**：管理一组相关对象的入口点，确保业务规则一致性。 - **领域服务（Domain Service）**：封装跨多个实体的业务逻辑。 - **通用语言（Ubiquitous Language）**：开发团队和领域专家共享的词汇表，确保沟通一致。例如，在银行系统中，“转账”操作应使用业务术语而非技术术语[^1][^2]。 这些概念不是生搬硬套的，而是从业务中抽象出来的。引用[^3]强调，DDD 的精髓在于理解业务本质，而非过度设计概念体系。否则，会增加系统复杂性，适得其反。 #### 2. **DDD 实践：从案例到应用** 实践 DDD 时，需从业务问题出发，逐步重构模型。以下基于引用[^2]的转账案例，说明如何应用 DDD。 **案例背景**：转账需求涉及用户账户间的资金转移。传统设计可能导致代码耦合，如违反单一职责原则（一个类处理数据库、逻辑和外部服务）。 **问题分析**： - 传统设计：直接调用数据库和第三方支付服务，业务逻辑分散，难以测试。 - 违反原则：高耦合导致修改风险（如添加新支付方式需改动多处）[^2]。 **使用 DDD 重构**： 1. **抽象数据存储层**：创建仓储（Repository）接口，隔离数据库操作。例如，定义 `AccountRepository` 接口，隐藏具体实现。 2. **抽象第三方服务**：通过适配器模式封装支付网关，确保领域模型不依赖外部细节。 3. **封装业务逻辑**：在聚合根中实现核心规则。例如，`TransferService` 作为领域服务，处理转账逻辑： - 检查账户余额。 - 确保事务一致性（通过聚合根管理）。 - 使用通用语言定义方法名（如 `transferFunds(fromAccountId, toAccountId, amount)`）。 4. **重构后的架构**： - 分层设计：用户界面层 → 应用层（协调服务） → 领域层（业务逻辑） → 基础设施层（数据库/外部服务）。 - 结果：代码更清晰，测试更容易，业务变化时只需修改领域层[^2]。 **实践建议**： - **避免误区**：引用[^3]指出，不要深陷概念体系（如过度讨论聚合根 vs. 值对象）。DDD 是工具，应从业务出发灵活取舍。例如，在 B 端营销系统中，简化事件模型，聚焦核心域。 - **适用场景**：DDD 适合复杂业务系统（如金融、电商），其中业务规则频繁变化。在微服务架构中，限界上下文可自然映射到服务边界[^1][^3]。 - **挑战**：团队协作是关键，需定期与领域专家对齐通用语言。 #### 3. **DDD 教程资源与学习路径** 学习 DDD 应结合理论和实践。推荐以下资源： - **入门教程**： - 阅读引用[^1]提到的[领域驱动设计（DDD）编码实践文章](链接)，它通过实际案例和代码示例（如 Java/Python），深入讲解战术设计模式。 - 免费资源：Martin Fowler 的博客或 DDD 社区网站，提供基础概念解析。 - **书籍**： - 《领域驱动设计：软件核心复杂性应对之道》（Eric Evans 著）：经典著作，覆盖战略和战术设计。 - 《实现领域驱动设计》（Vaughn Vernon 著）：侧重实践，包含代码示例。 - **在线课程**： - Udemy 或 Coursera 的 DDD 课程（如 “Domain-Driven Design in Practice”），结合项目练习。 - **实战建议**： - 从小项目开始：尝试重构一个简单模块（如用户管理），应用限界上下文和聚合根。 - 工具支持：使用框架如 Spring Boot（Java）或 Django（Python）实现 DDD 分层。 - 社区参与：加入 DDD 论坛或 Meetup，分享经验[^1][^2]。 #### 总结 DDD 的核心是通过领域模型桥接业务与技术，但成功取决于团队对业务的抽象能力，而非生硬套用概念[^3]。实践时，优先解决业务问题，逐步引入战术元素。如果您是初学者，建议从引用[^1]的编码实践文章入手，再结合书籍深化理解。DDD 不仅能提升代码质量，还能在微服务等现代架构中发挥优势[^1][^2]。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值