我最近在用一个采用 DDD 思想的项目，但一直没完全理解它。这篇是我的学习笔记，希望能帮助同样刚接触 DDD 的朋友建立起整体的认识。
为什么会出现 DDD？
传统的分层架构（Controller → Service → DAO）在业务简单的系统里非常高效。但随着业务变得越来越复杂，很多团队发现一个普遍的问题：
技术代码写得越来越熟练，但业务逻辑却越来越混乱。
举个典型的例子：一个”订单”状态。在代码里，订单可能有 status 字段，电商团队写 status = 2 表示”已支付”，物流团队写 status = "paid"，报表团队又有一套 orderState。同一个业务概念，在不同系统里有着不同的表达。业务方说”改一下订单状态”，你根本不知道要改哪一行代码。
DDD（Domain-Driven Design，领域驱动设计）就是针对这类问题提出的方法论。它的核心思想是：
软件系统的复杂性和核心价值都在于业务领域本身，而不是技术实现。
因此，软件开发应该以”领域”为核心，让技术为业务服务，而不是让业务去迁就技术。
DDD 关注什么
DDD 大致可以分成两个层次：
| 层次 | 关注点 | 回答的问题 |
|---|---|---|
| 战略设计 | 系统边界、上下文划分 | 整个系统怎么拆？哪些是核心？ |
| 战术设计 | 代码内部的建模 | 一个模块内部的类怎么设计？ |
战略设计回答”拆成几块、边界在哪”，战术设计回答”每一块里面长什么样”。两者是递进关系：先定边界，再细化内部。
几个最常见的误解
接触 DDD 时，很容易陷入下面几个误区：
误解一：DDD 就是”领域模型 + 贫血/充血模型”
很多人一听说 DDD 就以为是”把业务逻辑塞进实体类里”。其实这只是战术设计里的一个细节。DDD 最重要的贡献是战略设计——教会大家如何划分业务边界，而这部分经常被忽略。
误解二：DDD 只适合大型项目
DDD 确实在复杂系统里收益最大，但这不意味着小项目不能用。关键在于建模思维：先把业务领域想清楚，再写代码。这个习惯对任何规模的项目都有价值。
误解三：DDD 是一种框架
DDD 不是框架，也不是某个库。它是一种思考和建模的方法论。你完全可以在 Spring Boot、Go、Node.js 里落地 DDD，也可以用手写代码的方式落地。
DDD 的核心价值
我觉得 DDD 最大的价值有三个：
- 统一语言：让业务人员和开发人员使用同一套术语交流，避免”鸡同鸭讲”。
- 清晰的边界：通过限界上下文划分系统边界，控制复杂度。
- 业务为核心：让软件模型贴近真实业务，业务变了代码知道怎么改。
小结
这篇文章只是 DDD 的”地图”，先建立整体印象。接下来的几篇笔记我会分别展开：
先从最重要的战略设计开始看吧，它决定了整个系统的骨架。