1 · 读书笔记：领域驱动设计

Domain-Driven Design

https://book.douban.com/subject/26819666/

• 是什么（What）— 一种围绕复杂业务建模的方法，不先追求架构形式，而是先澄清业务概念、术语和边界
• 为什么（Why）— 软件真正难的常常不是技术实现，而是业务概念混乱、沟通失真、系统边界失控带来的复杂度
• 怎么做（How）— 识别核心领域，建立统一语言，划分边界上下文，再用实体、值对象、聚合等工具把模型落进代码

1.1 · 核心观点：

DDD 的核心不是追求一套固定架构，而是在复杂业务中先把模型讲清楚，再让模型持续影响沟通、代码和系统边界。它真正想解决的，是业务概念混乱、术语不统一、上下文边界不清导致的认知复杂度。

这套方法最关键的抓手有三个：第一，识别 Core Domain，把最高设计成本投入最有业务价值、最复杂的部分；第二，建立 Ubiquitous Language，让业务术语在讨论、文档、接口和代码中保持一致；第三，划分 Bounded Context，接受同一概念在不同场景下可以有不同含义，在边界内求一致，在边界间做协作。

DDD 不等于微服务，也不只是 Entity、Value Object、Aggregate、Repository 这些战术工具。战术设计解决的是局部实现问题，战略设计中的上下文划分才更决定整体成败。业务简单时没必要重度使用 DDD；但当系统复杂度主要来自业务而非技术时，DDD 往往是更有效的解法。

1.2 · 启发点（关键洞察）：

1. 软件最难处理的复杂度，很多时候不是技术复杂，而是认知复杂。
2. 模型如果没有进入代码，就还不算真正成立。
3. 统一语言不是沟通技巧，而是模型本身的一部分。
4. 一个大系统不需要只有一个统一模型，关键是每个 Bounded Context 内部保持一致。
5. 微服务不是 DDD 的起点，边界清晰才是。
6. 战略设计通常比战术设计更影响系统长期质量。
7. 好模型不是一次设计出来的，而是在和领域专家持续对话中不断演化出来的。

1.3 · 行动：

1. 先问核心领域是什么，不要默认所有模块同等重要。
2. 先统一术语，再讨论实现，否则设计很容易建立在错位理解上。
3. 先划边界上下文，再决定模块、服务和接口如何拆分。
4. 区分 Entity 和 Value Object，避免无意义的“身份化设计”。
5. 用聚合定义一致性边界，而不是机械映射数据库关系。
6. 面对遗留系统或外部系统，用防腐层保护内部模型。
7. 持续检查代码是否真的表达了业务模型，而不只是技术分层的堆叠。

1.4 · 金句：

1. “The heart of software is its ability to solve domain-related problems for its user.” — Eric Evans
2. “When we set out to write software, we never know enough.” — Eric Evans
3. “Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code.” — Eric Evans
4. “A model is a selectively simplified and consciously structured form of knowledge.” — Eric Evans
5. “Software design is a constant battle with complexity.” — Eric Evans

1.5 · 参考：

1. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
2. Eric Evans, DDD Reference
3. Martin Fowler 关于 Bounded Context 与 Ubiquitous Language 的相关文章