Day 02 - 战略设计：限界上下文与上下文映射

📖 今日目标

1. 理解限界上下文（Bounded Context）的概念与作用
2. 掌握限界上下文的划分原则
3. 了解上下文映射的不同模式

核心概念

什么是限界上下文？

限界上下文（Bounded Context） 是DDD战略设计中最重要的概念之一，它明确划定了某个模型的范围和含义。

每个限界上下文内，有一个且只有一个模型

限界上下文的核心特征：

• 明确的边界：模型在这个边界内有明确的含义
• 独立的语言：内部使用通用语言，边界外可能含义不同
• 自主的技术实现：可以独立选择技术栈和数据存储

为什么需要限界上下文？

在没有限界上下文的情况下，系统会陷入"大泥球"（Big Ball of Mud）的状态：

• 所有概念混在一起，含义模糊
• 修改一处可能影响其他不相关的功能
• 团队沟通成本高，团队边界不清

限界上下文帮助我们：

• 降低复杂性
• 明确团队责任边界
• 支持独立演进

关键要点

1. 限界上下文的识别

限界上下文的划分通常基于：

• 业务边界：不同业务领域通常有不同的上下文
• 团队边界：不同团队负责的不同功能区域
• 技术边界：不同的技术实现或数据存储需求

常见示例：

• 电商系统：商品上下文、订单上下文、库存上下文、用户上下文
• 金融系统：账户上下文、交易上下文、结算上下文

2. 限界上下文与子域的关系

• 子域是从业务视角划分，关注"做什么"
• 限界上下文是从解决方案视角划分，关注"怎么做"

两者的对应关系：

• 核心子域 → 核心限界上下文（最关键）
• 支撑子域 → 支撑限界上下文
• 通用子域 → 通用限界上下文（可直接购买）

3. 上下文映射

限界上下文之间需要相互协作，上下文映射定义了这种协作关系：

模式	说明	适用场景
共享内核（Shared Kernel）	两个上下文共享部分模型	紧密协作的团队
客户-供应商（Customer-Supplier）	上游提供接口，下游消费	独立演进需求
防腐层（Anti-Corruption Layer）	一方转换另一方的模型	遗留系统对接
开放主机服务（Open Host Service）	提供公开协议	开放API
发布语言（Published Language）	基于通用转换格式	跨系统集成
顺从者（Conformist）	直接使用上游模型	无控制权时
单独团队（Separate Ways）	不集成，独立存在	没必要集成

4. 限界上下文不是微服务

• 限界上下文是业务边界，微服务是技术边界
• 一个限界上下文可能包含多个微服务
• 微服务不应该跨限界上下文
• 初期可以用单体架构实现限界上下文分离

5. 上下文映射的实践

1. 绘制上下文地图：识别所有限界上下文及其关系
2. 标注团队：明确每个上下文由哪个团队负责
3. 识别集成点：确定上下文之间的交互方式
4. 持续演进：随着对业务的深入理解持续调整

面试考点

问题1：限界上下文和模块有什么区别？

答案：

限界上下文和模块虽然都用于组织代码，但存在本质区别：

1. 边界强度不同：

   • 模块：代码组织手段，边界较弱，可以直接引用其他模块
   • 限界上下文：业务边界，边界强，有独立的模型和语言

2. 模型独立性：

   • 模块：所有模块共享同一个全局模型
   • 限界上下文：每个上下文有自己独立的模型，可能存在同名不同义的概念

3. 团队组织：

   • 模块：可能由同一个团队维护
   • 限界上下文：通常对应独立的团队或团队边界

4. 演进独立性：

   • 模块：必须一起部署和发布
   • 限界上下文：可以独立演进和部署

举例：在电商系统中，"商品"在商品上下文和营销上下文中含义不同：

• 商品上下文：关注库存、SKU、价格
• 营销上下文：关注活动、促销、优惠券

---

问题2：如何划分限界上下文？

答案：

限界上下文的划分需要综合考虑多个因素：

1. 业务边界法：

   • 分析业务流程，识别不同的业务能力
   • 每个核心业务能力可能成为一个限界上下文
   • 遵循"高内聚、低耦合"原则

2. 团队边界法：

   • 康威定律：设计系统的结构受限于产生该系统的团队组织
   • 如果两个功能需要频繁沟通才能协调，考虑合并
   • 如果两个团队几乎没有交集，考虑拆分

3. 语言边界法：

   • 同一术语在不同场景下含义是否一致？
   • 如果术语开始出现歧义，可能跨越了上下文边界
   • 限界上下文边界往往伴随术语含义的转变

4. 变化速率法：

   • 不同变化频率的业务应该拆分
   • 变化原因不同的业务应该拆分

实践建议：

• 不要过度设计，初期可以先粗粒度划分
• 随着对业务的深入理解持续重构
• 画上下文映射图帮助团队达成共识

实践思考

🎯 思考题：

假设你在设计一个外卖配送系统，考虑以下场景：

1. 用户下单、商家接单、配送员接单、订单完成
2. 涉及用户、商家、骑手、支付等多个角色
3. 不同团队负责不同模块

请分析：这个系统应该划分哪些限界上下文？它们之间的映射关系是什么？

---

📚 扩展阅读

• 《领域驱动设计》第3部分：战略设计
• 《实现领域驱动设计》第4章：战略设计
• Bounded Contexts - Martin Fowler

---

📅 学习进度

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

---

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

📚 导航

| ← Day 01 - 上一章 | Day 03 - 下一章 →