DDD：同一事务中创建订单并修改折扣是否合规？

核心结论 #

哪怕是创建新聚合（订单）加上修改已有聚合（客户的折扣），在同一个事务里完成依然违反DDD“单事务仅修改一个聚合”的原则。这个规则的核心是每个聚合都是独立的一致性边界，事务里只该维护单个聚合的状态一致性——不管是写入新聚合的状态，还是修改已有聚合的状态，只要涉及两个不同聚合，就破坏了聚合的边界职责。

为什么创建订单不算例外？ #

DDD里聚合的一致性边界，是为了保证聚合内部的状态变更符合业务规则，同时避免跨聚合的锁竞争和复杂事务。创建订单本质是向系统写入一个新的聚合状态，停用折扣是修改另一个聚合的状态，这俩操作分属不同的一致性边界，硬塞在同一个事务里会带来问题：

• 聚合职责乱套：订单聚合不该管客户折扣的生命周期，客户聚合也不该插手订单创建的逻辑
• 事务范围变大，锁冲突概率上升，系统性能受影响
• 后续业务变更时，两个聚合的耦合会让修改成本陡增

可行的重构方案 #

方案1：调整聚合边界，把操作收敛到单个聚合里 #

如果业务要求必须强一致（绝对不能出现订单创建了但折扣没停用，或者反过来的情况），可以重新梳理聚合设计：

• 把「用折扣下单」的逻辑放到Customer聚合里：给Customer加一个placeOrderWithDiscount(discountId, orderInfo)方法，内部先校验折扣是否有效，接着创建Order实体（至于是作为Customer的关联实体还是值对象，得看订单后续的生命周期需求），最后把对应折扣标记为失效。整个操作都在Customer聚合的边界内，事务只修改Customer聚合的状态，符合DDD规则。
• 注意：如果订单后续有独立的业务操作（比如改订单状态、退款等），这种设计可能不合适，这时得考虑方案2。

方案2：用领域事件实现最终一致性 #

如果业务能接受短暂的一致性延迟（比如订单创建后几秒内折扣才停用，业务上没风险），推荐用事件驱动解耦：

1. 创建订单的事务里，只完成Order聚合的持久化，同时发布一个OrderPlacedWithDiscount领域事件（包含客户ID、折扣ID、订单ID等信息）
2. 单独写一个事件处理器，监听这个事件，在独立事务里找到对应的Customer聚合，把指定折扣标记为失效
3. 为了防止事件丢失或重复处理，可以加事件重试、幂等校验的机制

方案3：调整业务规则（如果允许的话） #

跟业务方确认：是不是真的需要强一致？比如，能不能允许订单创建后，折扣在短时间内还能用，但通过后续的校验逻辑（比如重复用折扣时检查关联订单的状态）避免问题？如果业务规则可以调整，这种方式成本最低。

内容的提问来源于stack exchange，提问作者Mike