3. 业务领域建模：DDD（领域驱动设计）概述、限界上下文（Bounded Context）的识别与划分
在微服务与中台架构盛行的今天，模块边界拆分是否合理，直接决定了系统的可维护性与演进成本。领域驱动设计（DDD）提供了一套从业务出发、以领域模型为核心的方法论，帮助架构师将复杂的业务逻辑映射为清晰的软件模块。本节将重点介绍DDD的核心概念，并深入讲解限界上下文（Bounded Context）的识别与划分方法。
3.1 DDD 核心概念概述
DDD 由 Eric Evans 提出，其核心思想是：软件设计应当以领域（Domain）为核心，而非以数据表或技术框架为核心。DDD 将复杂的业务系统拆解为多个子域，并通过统一的语言（Ubiquitous Language）在团队内部达成共识。
| 概念 | 定义 | 在架构中的角色 |
|---|---|---|
| 领域（Domain） | 企业所从事的业务范围与知识体系 | 系统的核心业务逻辑所在，如电商中的订单、库存、支付 |
| 子域（Subdomain） | 对领域的进一步细分 | 分为核心子域、支撑子域、通用子域，决定资源投入优先级 |
| 限界上下文（Bounded Context） | 模型应用的边界，内部有统一的语言与模型 | 微服务拆分的主要依据，每个上下文对应一个独立模块或服务 |
| 实体（Entity） | 具有唯一标识、生命周期可追踪的对象 | 如订单（Order）、用户（User），通过ID区分 |
| 值对象（Value Object） | 描述属性，无唯一标识，不可变 | 如地址（Address）、金额（Money），可被共享 |
| 聚合（Aggregate） | 一组相关实体与值对象的组合，通过聚合根保证一致性 | 数据修改的最小单元，如订单聚合包含订单项、收货地址 |
| 领域事件（Domain Event） | 领域中发生的、业务人员关心的状态变化 | 用于跨上下文通信，如“订单已支付”触发库存扣减 |
架构提示： 在微服务拆分初期，不必追求完美的领域模型。建议先识别出核心子域与支撑子域，围绕核心子域构建高内聚的限界上下文，支撑子域可适当采用通用解决方案（如第三方支付SDK）。
3.2 限界上下文（Bounded Context）的识别方法
限界上下文是DDD中最重要的战术模式之一。它定义了模型的应用边界，边界内部保持一致的业务语言与模型结构，边界之间通过明确的接口进行通信。错误的边界划分会导致模型污染、耦合严重。
3.2.1 识别步骤
- 事件风暴（Event Storming）：组织业务专家与开发团队，通过贴纸或白板，梳理出业务全流程中的领域事件（如“订单已创建”、“库存已锁定”）。
- 识别命令与聚合：针对每个领域事件，找出触发该事件的命令（如“提交订单”），以及该命令所操作的聚合（如“订单聚合”）。
- 划分上下文边界：将强相关的聚合、事件、命令归入同一个上下文。判断依据包括：业务语言是否一致、数据一致性要求是否高、变更频率是否相近。
- 定义上下文关系：明确上下文之间的协作模式（如客户/供应商、共享内核、防腐层等）。
3.2.2 常见划分误区
| 误区 | 表现 | 后果 |
|---|---|---|
| 按数据表拆分 | 将“用户表”与“订单表”直接拆成两个服务 | 业务逻辑分散，跨服务事务频繁 |
| 按组织架构拆分 | 前端团队、后端团队各维护一个上下文 | 上下文边界与业务边界不匹配 |
| 过度追求通用 | 将“商品”上下文设计为所有业务共用 | 模型膨胀，难以满足不同场景的差异化需求 |
| 忽略上下文映射 | 拆分后不定义上下文间的关系 | 接口混乱，数据冗余，团队协作困难 |
避坑指南： 限界上下文不是越细越好。一个常见的经验法则是：如果两个聚合之间的数据一致性要求极高（如“订单”与“订单项”），它们应属于同一个上下文；如果允许最终一致性，则可以考虑拆分。
3.3 上下文映射（Context Mapping）与协作模式
当识别出多个限界上下文后，需要定义它们之间的协作关系。DDD 提供了多种上下文映射模式，用于指导接口设计与集成方式。
实践建议： 在微服务架构中，防腐层（ACL） 与 发布语言（Published Language） 是最常用的两种模式。ACL 用于保护核心领域不受外部模型污染，发布语言则通过领域事件实现松耦合的异步集成。
3.4 案例：电商系统的限界上下文划分
以典型的电商系统为例，展示如何通过DDD识别限界上下文，并定义上下文间的接口调用规范。
3.5 接口调用规范设计原则
在限界上下文划分完成后，需要为上下文间的接口调用制定规范。以下是基于DDD的接口设计原则：
- 优先使用领域事件进行异步通信：对于跨上下文的业务通知（如订单支付成功），采用事件驱动方式，降低耦合。
- 同步调用需定义防腐层：当下游上下文需要同步查询上游数据时，在下游侧构建ACL，将上游模型转换为下游所需的模型。
- 接口契约先行：使用OpenAPI或gRPC proto文件定义接口，确保双方团队对输入输出达成一致。
- 避免跨上下文事务：通过Saga模式或事件溯源保证最终一致性，而非使用分布式事务。
关键决策： 在电商系统中，“订单上下文”与“库存上下文”之间的库存扣减操作，建议采用最终一致性方案：订单创建时预占库存，支付成功后正式扣减。若支付失败，则通过补偿事件释放预占库存。这种方式比强一致性的分布式事务具有更好的性能与可扩展性。