读书笔记：领域驱动设计

2021-04-143 引用
BNSystem-design

Domain-Driven Design

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

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

核心观点：

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

这套方法最关键的三点，也是DDD里的战略设计，关注系统整体如何分解：

  1. 识别核心领域 Core Domain，把最高设计成本投入最有业务价值、最复杂的部分
  2. 建立统一语言 Ubiquitous Language，让业务术语在讨论、文档、接口和代码中保持一致
  3. 划分限界上下文 Bounded Context，接受同一概念在不同场景下可以有不同含义，在边界内求一致，在边界间做协作

当然还有战术设计，关注单个限界上下文内部如何建模。

启发点（关键洞察）：

  1. 软件最难处理的复杂度，很多时候不是技术复杂，而是认知复杂
  2. 领域模型如果没有进入代码，就还不算真正成立
  3. 统一语言不是沟通技巧，而是模型本身的一部分
  4. 一个大系统不需要只有一个统一模型，关键是每个 Bounded Context 内部保持一致
  5. 微服务不是 DDD 的起点，边界清晰才是：业务简单时没必要重度使用 DDD；但当系统复杂度主要来自业务而非技术时，DDD 往往是更有效的解法
  6. 战略设计通常比战术设计更影响系统长期质量：战术设计解决的是局部实现问题，战略设计中的上下文划分才更决定整体成败
  7. 好模型不是一次设计出来的，而是在和领域专家持续对话中不断演化出来的

行动：

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

金句：

  1. The heart of software is its ability to solve domain-related problems for its user.
  2. 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.
  3. A model is a selectively simplified and consciously structured form of knowledge.
  4. Software design is a constant battle with complexity.
  1. https://martinfowler.com/bliki/DomainDrivenDesign.html
  2. https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/february/best-practice-an-introduction-to-domain-driven-design
  3. https://blog.bytebytego.com/p/domain-driven-design-ddd-demystified

评论