用DDD拆解电商系统：从领域划分到微服务落地的完整指南

用DDD拆解电商系统：从领域划分到微服务落地的完整指南

在构建一个现代电商平台时，我们常常会陷入一种技术驱动的困境：一上来就讨论要用什么数据库、选择哪个微服务框架、如何设计RESTful API。然而，当业务逻辑日益复杂，促销规则千变万化，库存与订单的联动关系错综复杂时，我们往往会发现，最初精心设计的“优雅”架构，在业务需求的洪流面前变得脆弱不堪，代码库逐渐演变成一个难以理解和维护的“大泥球”。这正是领域驱动设计（Domain-Driven Design, DDD）试图解决的核心问题——它主张将复杂软件的核心复杂性，从技术实现中剥离出来，聚焦于对业务领域本身的深刻理解和建模。

DDD不是一套可以生搬硬套的框架或工具，而是一套思维方式和工作方法。它尤其适用于像电商这样业务规则复杂、变化频繁、且需要长期演进的系统。想象一下，你需要处理秒杀活动时库存的精准扣减、优惠券与会员折扣的叠加计算、订单状态在“待支付”、“已支付”、“待发货”、“已发货”、“已完成”、“已取消”之间的复杂流转，以及这些状态变化所触发的一系列后续动作（如扣库存、发消息、更新用户积分）。如果这些核心业务逻辑散落在各个服务、各个Controller的角落里，与数据库操作、消息队列发送等基础设施代码纠缠在一起，那么任何一次业务规则的调整都将是一场灾难。

本文将以一个典型的电商系统为蓝本，带你走过一次完整的DDD实践之旅。我们不会停留在理论概念的阐述，而是深入到事件风暴工作坊、限界上下文的识别与划分、聚合根与值对象的设计，并最终展示如何将这些领域模型落地为清晰、自治的Spring Cloud微服务。我们的目标是，让你手中的代码不仅能运行，更能清晰地表达业务意图，从容应对变化。

1. 破冰：从业务视角出发，开启事件风暴工作坊

在动手写一行代码之前，DDD强调团队（包括领域专家、产品经理、架构师和开发人员）必须就业务达成共识。事件风暴（Event Storming）是一种高效的协作工作坊形式，它通过可视化的方式，快速捕捉业务全景。我们以电商的“订单履约”核心流程为例，看看如何操作。

1.1 识别领域事件：业务已发生的“事实”

工作坊开始时，我们会准备一面巨大的白板或使用在线协作工具。第一步是找出所有的领域事件。领域事件是过去发生的、对业务有重要意义的事实，通常用“名词+动词过去式”表示，例如“订单已创建”、“商品库存已扣减”、“支付已成功”。

在这个阶段，鼓励所有参与者（尤其是熟悉业务的领域专家）畅所欲言，将想到的橙色便利贴贴到白板上。对于电商下单流程，我们可能会得到如下一系列事件：

• 用户已提交订单
• 订单已支付
• 库存已预扣
• 支付已超时关闭
• 订单已取消
• 库存已释放
• 订单已发货
• 物流单号已生成
• 用户已确认收货
• 订单已完成

注意：事件风暴是一个迭代和发现的过程，初期的事件列表可能不完整或存在重叠，这完全正常。重点是激发讨论，暴露大家对业务流程理解的差异。

1.2 梳理命令与聚合：谁触发了事件，谁记录了状态？

接下来，我们为每个领域事件寻找其触发者——命令（Command）。命令是导致事件发生的动作或意图，通常用“动词+名词”表示，例如“提交订单”、“支付订单”、“取消订单”。我们用蓝色便利贴代表命令，并放置在对应事件的左侧。

然后，我们需要思考：是谁“接收”了这些命令，并“记住”了事件发生后的状态变化？这就是聚合（Aggregate）。聚合是一组紧密关联、具有一致生命周期的事务单元，它内部封装了状态和业务规则，并通过一个聚合根（Aggregate Root）对外提供唯一的访问入口。我们用黄色便利贴表示聚合。

以“订单”为例：

• 命令：“提交订单”（由用户或前端应用发出）
• 聚合：“订单聚合”（其聚合根是Order实体）
• 事件：“订单已创建”（这是命令执行后产生的结果）

通过连接命令、聚合和事件，我们开始构建出业务流程的骨架。我们可能会发现，“库存已扣减”这个事件，可能由“提交订单”命令触发（预扣库存），也可能由“支付订单”命令触发（实际扣减），这引出了对库存管理复杂性的讨论。

1.3 划定限界上下文：业务能力的自然边界

随着事件风暴板的逐渐丰满，你会发现某些事件、命令和聚合自然地聚类在一起，形成一个内聚的业务概念单元。这个单元就是限界上下文（Bounded Context）。它是DDD中最重要的设计决策之一，定义了一个模型（即一套术语、概念、规则）的适用范围和边界。

在我们的电商系统中，通过分析，可以初步识别出几个核心的限界上下文：