2Implementing Domain-Driven Design

领域与领域模型

领域分析

子域限界上下文上下文映射通用语言

🎯 AI 时代的学习建议:不要只读理论。理解这一章的设计动机(为什么需要这个概念?)和边界条件(什么情况下会失效?)。当 AI 生成的代码涉及这些概念时,你能判断它是否用对了场景。AI 能帮你总结内容,但无法替代你亲手阅读、思考、建立直觉的过程。

第2章:领域与领域模型(Domains and Domain Models)

一、导读

1.1 本章学习目标

第2章深入讲解领域分析——如何从业务需求中提取领域模型。

本章的核心学习目标包括:

  • 理解子域(Subdomain)的分类
  • 掌握领域分析的方法
  • 学会识别核心域、支撑域、通用域
  • 理解上下文映射(Context Map)的模式

1.2 为什么本章如此重要

不是所有领域都同等重要。核心域是企业的竞争优势,应该投入最多资源;通用域可以用现成方案。正确分类子域,才能合理分配资源。

1.3 核心问题引导

核心域、支撑域、通用域有什么区别?

如何进行领域分析?

上下文映射有哪些模式?

如何决定限界上下文的边界?


二、核心概念详解

2.1 子域分类

核心域(Core Domain):
- 企业的核心竞争力
- 需要最大投入
- 不应该用通用方案

支撑域(Supporting Subdomain):
- 支持核心域运作
- 有一定的业务特殊性
- 可以适度定制

通用域(Generic Subdomain):
- 通用的业务功能
- 可以用现成方案
- 不应该过度投入

2.2 上下文映射模式

上下文之间的关系模式:

1. 共享内核(Shared Kernel)
   - 两个上下文共享一部分模型
   - 需要同步修改

2. 客户-供应商(Customer-Supplier)
   - 上游为下游提供服务
   - 有明确的协议

3. 遵从者(Conformist)
   - 下游完全遵从上游的模型
   - 没有协商余地

4. 防腐层(Anti-Corruption Layer)
   - 在两个上下文之间建立翻译层
   - 隔离外部模型的影响

5. 开放主机服务(Open Host Service)
   - 为多个消费者提供标准协议
   - 如 REST API、gRPC

6. 发布语言(Published Language)
   - 使用标准格式交换数据
   - 如 JSON Schema、Protobuf

2.3 领域分析方法

领域分析步骤:

1. 事件风暴(Event Storming)
   - 识别领域事件
   - 找出触发事件的原因
   - 确定事件后的命令

2. 用户故事分析
   - 从用户视角理解业务
   - 提取业务概念和规则
   - 识别业务流程

3. 业务流程建模
   - 绘制业务流程图
   - 识别参与者和系统
   - 确定系统边界

三、实战案例

3.1 案例一:事件风暴

电商订单流程的事件风暴:

领域事件:
- OrderPlaced(订单已下单)
- PaymentReceived(收到付款)
- OrderConfirmed(订单已确认)
- ShipmentCreated(已创建发货单)
- ShipmentDelivered(已送达)

命令:
- PlaceOrder(下单)
- ProcessPayment(处理支付)
- ConfirmOrder(确认订单)
- CreateShipment(创建发货单)

聚合:
- Order(订单)
- Payment(支付)
- Shipment(发货)

上下文映射:
- Order → Payment:客户-供应商
- Order → Shipping:防腐层
- Order → Inventory:共享内核

四、本章小结

子域分类:核心域(竞争力)、支撑域(支持)、通用域(通用)。

上下文映射:共享内核、客户-供应商、防腐层等模式。

领域分析:事件风暴、用户故事、业务流程建模。


五、思考与练习

为一个电商系统识别核心域、支撑域和通用域。

选择合适的上下文映射模式来连接订单和支付上下文。

用事件风暴分析一个你熟悉的业务流程。


2/7领域与领
0%