4. 领域建模方法论：事件风暴工作坊、四色建模法与六边形架构
领域建模是API设计治理的核心环节，它决定了服务边界的合理性与接口映射的准确性。本章深入剖析三种主流的领域建模方法论——事件风暴工作坊、四色建模法与六边形架构，并阐明它们与领域模型的内在关系，帮助你在实践中选择最合适的建模策略。
4.1 事件风暴工作坊：协作式领域探索
事件风暴（Event Storming）是由Alberto Brandolini提出的一种高度协作的、基于粘滞便签的领域建模工作坊技术。它通过跨职能团队的实时讨论，快速发现业务事件、命令、聚合与限界上下文。
4.1.1 核心元素与颜色约定
| 元素类型 | 颜色 | 描述 | 示例 |
|---|---|---|---|
| 领域事件 | 橙色 | 业务中已发生的事实，不可变 | 订单已提交、支付已完成 |
| 命令 | 蓝色 | 触发领域事件的用户意图或系统动作 | 提交订单、确认支付 |
| 聚合 | 黄色 | 具有完整事务边界的一致性根实体 | 订单、账户、库存项 |
| 外部系统 | 粉色 | 与系统交互的第三方或遗留系统 | 支付网关、物流API |
| 用户/角色 | 绿色 | 执行命令的参与者 | 买家、客服、管理员 |
| 限界上下文 | 边界线 | 划分模型边界的逻辑容器 | 订单上下文、支付上下文 |
4.1.2 工作坊流程
- 混沌探索：所有参与者自由粘贴领域事件，不设限制，形成事件流。
- 时间线排序：按时间顺序排列事件，识别事件之间的因果关系。
- 命令与角色注入：为每个事件找到触发它的命令和执行命令的角色。
- 聚合发现：围绕事件和命令，识别出具有事务一致性的聚合根。
- 限界上下文划分：根据业务语义和变化频率，将聚合分组到不同的限界上下文中。
- 热点与问题标记：使用红色便签标记不确定或有争议的区域，后续深入讨论。
实践要点：事件风暴的核心价值在于“对话”而非“文档”。建议每次工作坊控制在2-4小时，参与者包括领域专家、产品经理、开发者和测试人员。最终产出物是一张物理或数字化的“事件风暴墙”，它直接映射为领域模型的骨架。
4.1.3 从事件风暴到领域模型
事件风暴的产出物可以直接转化为领域模型中的核心构造：
- 领域事件 → 事件类（Event Class），通常以过去时态命名。
- 聚合 → 聚合根实体（Aggregate Root），包含业务逻辑与不变条件。
- 命令 → 应用服务方法或命令对象（Command Object）。
- 限界上下文 → 模块（Module）或微服务候选边界。
4.2 四色建模法：稳定与变化的分离
四色建模法（Four-Color Modeling）由Peter Coad提出，它使用四种颜色原型来捕捉业务模式，强调将稳定的业务核心与易变的外围逻辑分离。这种方法特别适合构建可演化的领域模型。
4.2.1 四色原型定义
| 颜色 | 原型名称 | 含义 | 典型示例 |
|---|---|---|---|
| 红色 | 时刻-时段（Moment-Interval） | 业务中需要在某个时刻或时段内记录的事件 | 销售订单、租赁合同、就诊记录 |
| 绿色 | 角色（Role） | 参与者在特定上下文中扮演的身份 | 买家、卖家、医生、患者 |
| 蓝色 | 描述（Description） | 对事物的分类或目录信息 | 产品目录、服务类型、费率表 |
| 黄色 | 参与方-地点-物品（Party-Place-Thing） | 业务中的核心实体，不随时间变化 | 客户、仓库、设备 |
4.2.2 建模步骤
- 识别红色原型：找出所有需要被记录的业务“时刻”或“时段”，如订单创建、支付完成。
- 关联黄色原型：确定参与这些时刻的实体，如客户、商品。
- 提取绿色角色：分析实体在不同上下文中扮演的角色，如“客户”在订单上下文中是“买家”。
- 补充蓝色描述：为实体添加分类或描述信息，如商品类别、价格等级。
- 验证模型稳定性：检查黄色和蓝色原型是否足够稳定，红色和绿色原型是否覆盖了所有业务变化点。
四色 vs 事件风暴：事件风暴更适合从零开始的探索性建模，而四色建模法更适合已有业务知识沉淀后的精细化建模。两者可以互补使用：先用事件风暴发现领域事件和聚合，再用四色法对聚合内部进行原型分析。
4.3 六边形架构与领域模型的关系
六边形架构（Hexagonal Architecture），又称端口与适配器架构，由Alistair Cockburn提出。它强调领域模型处于架构中心，与外部基础设施完全解耦，通过端口（Port）和适配器（Adapter）实现内外交互。
4.3.1 架构分层
- 领域层（核心）：包含实体、值对象、聚合、领域服务、领域事件。不依赖任何外部框架或数据库。
- 应用层：编排领域对象完成用例，包含应用服务、命令处理、事件发布。依赖领域层接口。
- 端口层：定义入站端口（Inbound Port）和出站端口（Outbound Port），即接口抽象。
- 适配器层：实现端口接口，包括Web适配器（REST API）、持久化适配器（Repository实现）、消息适配器等。
4.3.2 端口与适配器模式
端口是领域层定义的接口，适配器是基础设施层对端口的实现。这种模式实现了依赖倒置原则（DIP）：
// 领域层定义出站端口（接口）
public interface OrderRepository {
Order findById(OrderId id);
void save(Order order);
}
// 基础设施层实现适配器
public class JpaOrderRepository implements OrderRepository {
@Override
public Order findById(OrderId id) {
// JPA实现逻辑
}
@Override
public void save(Order order) {
// JPA实现逻辑
}
}4.3.3 六边形架构对API设计的影响
- 接口稳定性：入站端口直接对应API的Service接口，领域模型的变化不会直接导致API契约变更。
- 测试友好：领域层可独立进行单元测试，适配器可被Mock替换。
- 技术无关性：API的暴露方式（REST、gRPC、GraphQL）由适配器决定，领域模型无需感知。
4.4 三种方法论的协同应用
在实际项目中，三种方法论并非互斥，而是可以形成递进式的建模流水线：
- 事件风暴：快速探索业务全景，发现领域事件、聚合和限界上下文。
- 四色建模：对每个限界上下文内的聚合进行原型分析，分离稳定与变化部分。
- 六边形架构：将领域模型置于架构中心，通过端口与适配器隔离外部技术细节。
常见误区：不要试图在一次工作坊中同时完成三种建模。建议分阶段进行：先完成事件风暴获得全局视图，再选择核心限界上下文进行四色建模，最后在编码阶段落地六边形架构。过度建模会导致团队陷入细节而失去业务焦点。
4.5 本章小结
事件风暴工作坊提供了快速发现领域知识的协作框架，四色建模法帮助我们在聚合内部实现稳定与变化的分离，六边形架构则确保了领域模型在技术演进中的独立性。三者共同构成了从业务探索到技术实现的完整建模路径，为后续的API服务边界划分和接口映射奠定了坚实的领域基础。