我们是否应该因为边缘情况而使聚合根复杂化？

Question

假设我们正在实现一个使用事件源的支付系统，并拥有PaymentCreated、PaymentAuthorized、PaymentSettled和PaymentInvoiced等事件

很明显，支付应该是我们的聚合根，所有的操作都发生在它上面。

但也有退款。退款基本上是一种付款，唯一的区别是它的金额是负的，它必须引用我们正在退款的付款。在所有其他方面，它的行为都像正常支付一样。它具有相同的状态和事件集，所有外部系统都以与正常支付相同的方式处理退款。

更有趣的是，可以有多个部分退款，但退款金额的总和必须小于或等于原始付款金额。

我们基本上有两个选项来实现它。

a)作为聚合根的付款-缺点是，当检查退款限制时，我们必须锁定付款，我们正在退款并检查其他退款。换句话说，退款初始化使用多个聚合根进行操作，这是不推荐的。

b)“支付组”作为聚合根-我们可以将原始支付及其所有退款放在一个聚合中，该聚合可以强制执行不变量。缺点是，系统中的大多数操作都是在一个付款/退款级别上执行的，因此模型与用例不匹配。假设第三方通知我们付款/退款已结清。我们得到一个外部ID，我们必须通过这个ID找到支付组，并在那里找到付款(使用相同的ID)。这似乎不必要地使大部分代码复杂化，只是为了确保退款中的一个不变量。

你有什么推荐的？

Answer 1

amount.

• Refunds validation.

• There

1. 您有一个业务约束，即退款金额不能低于原始付款可能会部分发生，因此每个交易都必须经历此过程中可能会有多个退款，因此您需要确保退款检查和处理作为一个事务处理的一部分发生。

因此，您的退款和付款是同一事务一致性边界的一部分。应该有一个聚合，Payment，并且您的Refund必须是它的一部分。所有退款交易都必须通过Payment聚合进行路由。

在DDD术语中，Refund是属于Payment聚合的域模型中的一个实体。