domain-driven-design - 保持聚合之间的一致性

Question

我想知道如何解决聚合之间的事务一致性问题。我的第一印象是，每当您需要聚合之间的事务一致性时，您就错误地设计了聚合。但是，我仍然想问这个问题，以确保我没有遗漏任何东西。

想象一下你卖牛奶。您有多头奶牛，每头奶牛每天生产一定量的牛奶。您需要有一项能够获取库存牛奶数量的服务。除此之外，您还应该能够订购牛奶。根据此信息，您可以创建三个聚合，Cow , Stock和 Order .每当订购一定数量的牛奶时，业务规则之一是检查该数量是否有库存，如果没有，立即让用户知道。当两个用户同时进行请求并订购了 150 升牛奶，而只有 130 升牛奶可用时，如何实现这一点？我的第一个想法是您可以通过乐观/悲观锁定来实现这一点，但在这种情况下，一个聚合依赖于另一个。有没有办法解决这个特定问题，或者这只是糟糕的聚合设计？

Answer 1

My first impression is that whenever you need transactional consistency between aggregates, you wrongly designed your aggregates.

完全正确；发现聚合边界的方法是首先确定需要保持一致的值，然后选择具有以下属性的边界:任何两个需要相互一致的值都在同一边界内。

注意:我们并不总是正确的；也许需求是错误的，也许我们的模型不够充分，也许业务发生了变化。部分挑战是确保用更好的模型替换当前模型总是很容易。

Based on this information you can create three aggregates, Cow, Stock and Order.

注: Cow是一个糟糕的聚合——假设我们谈论的是世界上真正吃草的奶牛。它是一个实体，是的，但它不受模型的影响。如果模型说奶牛是空的，而奶牛说它装满了牛奶，那么奶牛是对的。

同样，如果奶牛是真实的，那么你的大部分股票也是真实的。如果模型说有七个满 jar 的牛奶，而农民数了六个，那么六个就是正确的答案。

聚合是信息资源。

Whenever a certain amount of milk is ordered, one of the business rules is to check if that amount is in stock and if not, let the user know right away. How can this be achieved when two users do a concurrent request and order a total amount of 150 liters milk, while only a 130 liters are available?

关于“立即”要意识到的重要事情；你在这里，用户(买家？)在那里。通信中有一定的延迟，这意味着您发送给买家的信息在到达时已经过时。 (从技术上讲，它在您发送时已经过时了。)

第二次履行订单需要了解订单和可用库存。因此，您可以将其建模为可以完成所有操作的单个聚合，或者您可以将其建模为与某些履行聚合异步通信的订单聚合；例如，Stock 真正做的可能是将可用牛奶的通知与待处理订单相匹配。

在您的并发处理示例中，这看起来像两个命令，用于预留 130 升牛奶，同时针对具有 150 升牛奶可用的库存总量运行。使用乐观并发，这两个命令都会发现有足够的牛奶来满足订单，并尝试更新记录簿。然而，该更新是序列化的——认为事务，或比较和交换——所以其中一个命令成功，而另一个则得到并发修改异常。因此，第二个命令再次尝试，以新状态重新加载库存。这一次，它发现可用库存不足，并采取相应措施(将订单移入等待列表，通知买家预期的履行日期等)。

请注意，当保留牛奶的命令与有更多牛奶可用的通知并行运行时，您还会收到并发修改异常。