Day 01 - DDD初识：什么是领域驱动设计

📖 今日目标

1. 理解什么是领域驱动设计（DDD）
2. 掌握DDD的核心价值和应用场景
3. 了解DDD与传统开发方式的区别

核心概念

什么是领域驱动设计？

领域驱动设计（Domain-Driven Design，简称DDD） 是一种软件开发方法论，由Eric Evans在2003年出版的《Domain-Driven Design》一书中提出。它的核心思想是：

将业务领域的核心逻辑作为软件设计的中心

DDD不是一种框架，也不是一种编程语言，而是一种思考方式和设计理念。它帮助我们：

• 把复杂业务从技术实现中剥离出来
• 让开发者和业务专家能够用同一种语言沟通
• 构建出更加健壮、可维护、可扩展的软件系统

核心术语

术语	英文	说明
领域	Domain	业务问题所在的范围，是你要解决的业务问题本身
子域	Subdomain	将大领域拆分成多个小领域，便于理解和处理
限界上下文	Bounded Context	明确划定模型的边界，每个上下文有自己独立的含义
通用语言	Ubiquitous Language	开发团队与业务专家共同创建的一套统一的语言
领域模型	Domain Model	对业务领域知识的抽象表示

关键要点

1. 以业务为核心

传统开发往往以技术为导向：我们先想用什么框架、什么数据库、什么架构，然后才考虑业务逻辑。

DDD反其道而行之：先深入理解业务，再选择技术实现。

传统方式：技术 → 业务
DDD方式：业务 → 技术

2. 统一语言的重要性

大多数项目中，开发者和业务人员说的不是同一套话。比如"订单"这个词：

• 业务说：客户提交的需求清单
• 开发理解：数据库里的一张表

DDD强调通过通用语言（Ubiquitous Language） 让团队用一致的术语沟通，减少误解。

3. 限界上下文划定边界

每个系统都有其明确的边界。在这个边界内，某个概念有且只有一个含义。

比如电商系统中：

• 退货上下文中的"订单状态"与物流上下文中的"订单状态"含义不同
• 通过限界上下文划分，避免概念混淆

4. 领域模型不是数据库模型

这是最容易犯的错误。DDD中的领域模型是对业务行为的抽象，而不是对数据库表的映射。

❌ 错误理解：Order = orders表
✅ 正确理解：Order = 一个包含订单创建、修改、取消等行为的业务实体

5. 战术设计与战略设计

DDD分为两个层次：

• 战略设计：从宏观角度划分限界上下文、建立上下文映射、组织代码架构
• 战术设计：从微观角度实现实体、值对象、聚合、领域服务、仓储等模式

传统开发 vs DDD

对比项	传统开发	DDD
核心关注	技术实现	业务逻辑
模型来源	数据库表结构	业务行为
语言统一	各说各话	通用语言
代码组织	按技术分层	按业务领域组织
边界划分	模糊，随意	明确的限界上下文
适用场景	简单CRUD	复杂业务系统

何时应该使用DDD？

适合使用DDD的场景 ✅

• 业务逻辑复杂，存在大量业务规则
• 团队中业务专家与技术人员沟通频繁
• 系统需要长期维护和演进
• 微服务架构，需要明确服务边界
• 需要处理多业务线或多产品线

不适合使用DDD的场景 ❌

• 简单的CRUD应用
• 数据处理为主的应用
• 短生命周期的项目
• 业务逻辑简单的工具类应用

面试考点

问题：DDD的核心价值是什么？为什么要使用DDD？

答案：

DDD的核心价值体现在以下几个方面：

1. 业务与技术对齐：DDD将业务逻辑放在软件设计的中心，确保技术实现真正服务于业务需求，而不是反过来被技术绑架。

2. 解决沟通障碍：通过建立通用语言，开发者和业务专家可以用一致的术语沟通，减少需求理解和实现的偏差。

3. 应对复杂性：对于复杂业务系统，DDD通过限界上下文划分、领域模型抽象，帮助团队更好地理解和管理复杂性。

4. 提升代码可维护性：以业务为中心的代码组织方式，使得代码更易于理解和修改，即使业务人员也能参与代码评审。

5. 支持业务演进：良好的领域模型设计让系统更容易适应业务变化，降低修改成本。

总结：DDD不是银弹，但在处理复杂业务系统时，它提供了一套经过验证的方法论，帮助团队构建出更加健壮、可持续演进的软件系统。

---

问题：DDD中的"领域"具体指什么？

答案：

在DDD中，"领域（Domain）"指的是业务问题所在的范围，即你要解决的业务问题本身。

具体理解：

1. 领域的定义：领域是一个组织所做的工作及其背后的业务逻辑。例如，电子商务领域包含商品管理、订单处理、库存管理、物流配送等业务。

2. 领域是一个边界：它划定了系统要解决问题的范围，超出这个范围的不是当前系统需要关注的。

3. 领域的拆分：复杂领域可以拆分为多个子域（Subdomain）：

   • 核心域（Core Domain）：业务的核心竞争力，是系统最重要的部分
   • 支撑域（Supporting Subdomain）：支撑核心域的功能
   • 通用域（Generic Subdomain）：可以购买或复用的通用功能

例如，电商系统的领域可以拆分为：

• 核心域：商品、订单、支付
• 支撑域：库存、物流
• 通用域：用户、通知

核心要点：领域不是技术概念，而是业务概念，关注的是"这个系统要解决什么问题"，而不是"用什么技术实现"。

实践思考

🎯 思考题：回顾你参与过的项目，思考以下几个问题：

1. 业务逻辑最复杂的是哪个模块？是如何处理的？
2. 开发团队和业务团队在沟通时是否经常出现理解偏差？
3. 如果让你重新设计某个模块，你会如何组织代码结构？

---

📚 扩展阅读

• 《领域驱动设计》- Eric Evans（DDD奠基之作）
• DDD官方资源
• Martin Fowler's DDD Overview

---

📅 学习进度

Day	主题	状态
01	DDD初识：什么是领域驱动设计	✅
02	战略设计：限界上下文与上下文映射	⬜
03	战略设计：通用语言与领域建模	⬜
...	...	...
29	实战项目：电商领域建模	⬜
30	复习与总结	⬜

---

本文为DDD 30天学习计划第1天内容

📚 导航

| Day 02 - 下一章 →