面对日益复杂的软件系统，如何让代码结构清晰反映业务本质，是每个架构师和开发者面临的挑战。领域驱动设计（DDD）为我们提供了一套从战略到战术的系统化方法论。今天，我们就来深入剖析 DDD 中最宏观、最关键的环节——战略设计。
你可以把它理解为绘制一幅精确的“业务地图”。在这张地图上，复杂的商业王国被清晰地划分为若干行政区（子域），每个行政区有自己的法律和语言（限界上下文和通用语言），并且行政区之间有着明确的通行和协作规则（上下文映射）。
1. 战略设计：绘制业务地图
1.1 概念
战略设计是 DDD 的高层规划阶段，其核心目标是解构业务复杂性，界定系统边界，定义团队协作模式。它不关心“类”如何实现（那是战术设计的事），而关注如何将庞大的业务领域划分成可理解、可管理、可独立演进的模块。这对构建清晰、可持续演进的软件架构至关重要。
大白话类比
想象一下，你要开发一个“智慧城市”系统。战略设计就是城市规划总署的工作。总署并不关心某栋大楼的内部装修细节（战术设计），而是先要规划出：哪里是金融区、哪里是住宅区、哪里是文教区（业务领域分类），每个区的边界和法律是什么（限界上下文），并且规定各区之间如何修路、如何互通有无（上下文映射）。没有这个顶层规划，城市发展就会陷入混乱。
1.2 产出
战略设计的交付物是一张架构蓝图，它明确了：
- 业务领域分类：系统包含哪些核心业务板块。
- 限界上下文：每个业务板块的精确边界。
- 通用语言：在每个边界内，所有人（开发、产品、业务）使用的无歧义术语。
- 上下文映射图：描绘了各个部分如何协作的关系图。
1.3 工作流程
战略设计的工作流程通常包括：事件风暴会议、识别子域、划定限界上下文、绘制上下文映射。
2. 业务领域分类：划分商业王国
2.1 为什么要对业务领域分类
面对一个庞大系统（如淘宝、美团），直接下手开发是不可能的。必须采用“分而治之”的策略，将大问题分解为小问题。业务领域分类就是这种思想的体现，它将复杂的业务领域分解为不同的“子域”。
2.2 核心域
核心域是企业的核心竞争力，是业务成功的关键。需要重兵投入，精耕细作。这是公司的核心竞争力和差异化优势所在。
2.3 支撑域
支撑域不直接体现核心竞争力，但为核心域提供专业化支撑。需要专业支撑，保障核心。虽然不是业务的卖点，但没有它核心业务玩不转。
2.4 通用域
通用域是非业务核心，且存在行业通用解决方案的领域。需要采购或外包，性价比优先。这类功能非常通用，自己开发成本高，不如使用现成的优秀方案。
2.5 核心域、支撑域、通用域的对比
| 子域类型 |
概念 |
核心关注点 |
真实案例（以电商系统为例） |
| 核心域 |
企业的核心竞争力，是业务成功的关键。 |
重兵投入，精耕细作 |
交易域（下单、支付、购物车）。这是电商的命脉，需要投入最好的架构师和开发人员。 |
| 支撑域 |
不直接体现核心竞争力，但为核心域提供专业化支撑。 |
专业支撑，保障核心 |
商品域（商品管理、类目）、用户域。它们专门为交易域提供必要的“弹药”和“燃料”。 |
| 通用域 |
非业务核心，且存在行业通用解决方案的领域。 |
采购或外包，性价比优先 |
登录认证域、消息通知域。可以直接使用阿里云的身份认证服务或第三方短信服务。 |
3. 限界上下文
3.1 概念
限界上下文是一个语义和语境的边界，在这个边界内，领域模型（概念、术语、规则）是自洽且无歧义的。它通常是子域在技术层面的落地体现。
3.2 作用
- 消除歧义：防止同一个词在不同场景下有不同含义造成的混乱。例如，“产品”在商品上下文指代可售卖的商品，而在订单上下文中可能指订单项。
- 高内聚，低耦合：限界上下文内部高度内聚，外部通过明确的接口进行松耦合的协作。
- 指导微服务拆分：一个限界上下文通常可以设计为一个独立的微服务，天然契合微服务架构的理念。
下面的图表通过一个电商平台的例子，展示了战略设计如何从业务需求出发，通过识别子域和划定限界上下文，最终形成清晰的系统模块划分。
4. 限界上下文映射
当不同的“行政区”（限界上下文）划定后，它们之间如何协作就成了关键。上下文映射就是定义这些协作关系的“外交协议”。
4.1 概念与作用
上下文映射是一种识别和管理不同限界上下文之间关系的技术。它明确了不同团队（每个团队负责一个限界上下文）之间应该如何集成和通信，防止出现混乱的“点对点”集成，从而提升整个系统的协作效率与健壮性。深入理解这些协作模式，是掌握系统设计精髓的关键一步。
4.2 核心映射关系
以下是一些关键的上下文映射关系模式：
- 防腐层：当一个上下文需要与另一个设计拙劣或概念不同的上下文交互时，防腐层充当翻译官和适配器，将外部模型转换成本地模型，避免“污染”自己的领域模型。例如，您的“交易上下文”在接入一个设计粗糙的“第三方物流系统接口”时，需要设立防腐层来转换数据。
- 开放主机服务 + 发布语言：将一个上下文通过一组公开的、协议明确的API提供给其他上下文使用。这组 API 就是“开放主机服务”，而 API 所使用的标准协议（如 RESTful 规范）就是“发布语言”。这就像国家开设了一个标准化的口岸供国际贸易。
- 客户-供应商：两个需要协作的上下文，其中“下游”上下文高度依赖“上游”上下文。双方需要建立一种合作模式，下游提出需求，上游尽力满足。例如，“报表上下文”（下游）依赖“交易上下文”（上游）提供准确的数据。
- 合作伙伴：两个上下文相互依赖，一荣俱荣，一损俱损，必须共同进退。例如，在一个复杂流程中，“订单上下文”和“库存上下文”必须同时成功或失败，它们就是合作伙伴关系，通常需要使用分布式事务来保证一致性。
- 共享内核：两个团队共享一小部分领域模型（代码、数据库表）。这部分模型需要被严格管理，任何修改都需要双方团队一致同意。这就像两个相邻城市共享一个水库及其管理规则。这是一种强耦合的模式，需谨慎使用。
5. 记忆技巧以及解题技巧
核心口诀：
战略设计画地图，业务复杂能解构。
核心支撑通用域，资源分配要清楚。
限界上下文划边界，语言统一无歧义。
上下文映射定关系，协作顺畅不扯皮。
实战技巧
- 从事件风暴开始：组织包括领域专家、产品、开发在内的跨职能会议，通过贴便利贴的方式梳理业务流、领域事件、命令等，这是发现领域概念和关系的最佳实践，相关的方法论可以在技术文档中找到详细指引。
- 聚焦核心域：将最优秀的人才和资源投入到核心域的设计和开发中，这是项目的成败关键。
- 边界优于实现：初期不要过度纠结于技术细节（如用什么数据库），而要花大量时间讨论和确认限界上下文的边界，这比任何技术选项都重要。
- 拥抱演进：战略设计不是一蹴而就的。随着业务发展，限界上下文可能需要拆分或合并，要保持架构的演进能力。
希望这篇关于 DDD 战略设计的梳理，能帮助你更好地驾驭复杂业务系统的顶层设计。理论结合实践，才能在云栈社区等开发者平台与同行交流时，更有底气地探讨架构的真谛。 | 
发表于 昨天 05:26
|
查看: 0|
回复: 0
