聚合之间的 DDD 事件示例答案

【问题标题】：DDD Events Between Aggregates Example聚合之间的 DDD 事件示例
【发布时间】：2020-07-21 22:44:06
【问题描述】：

我有两个聚合

项目和价格调整。

价格调整将包含项目调整，即对于特定项目，将其提高 x%（例如 10%）

我的商品有一个需要更新/调整的标价。

因此，在处理价格调整时，它将找到该项目并需要按特定百分比调整该项目的标价。调整完成后，需要将调价中的项目调整标记为完成

我的问题是，这种对标价的更新和对商品调整的标记是如何组成事件的？

我更新标价并将项目调整标记为已完成以下事件的正确方法是什么？

这是一个正确的解决方案吗？：

调用AdjustListPrice等item函数，传入要调整的id、百分比等价格调整信息。
然后引发诸如 ItemListPriceAdjusted 之类的事件，让价格调整监听，以便它可以将调整标记为完成并引发另一个事件，例如 itemPriceadjustmentCompleted

如果这是正确的方法，是否应将新计算的标价添加到 ItemListPriceAdjusted 价格中，还是应仅添加调整百分比，然后在应用/从聚合中读取时计算？

谢谢

编辑：

我目前使用的选项是在处理价格调整时，它将通过每个项目调整。

它将找到它所针对的项目并调用该函数 AdjustPrice(Guid priceAdjustmentId,小数adjustmentPercentage)

这将计算该商品的新标价，并且该商品将发出一个 ItemPriceAdjusted 事件，其中包含价格调整 ID、新标价和新标价

然后价格调整将监听这些事件并将相关的项目调整标记为完成，进而发出自己的 ItemAdjustmentCompleted 事件

【问题讨论】：

标签： events aggregate domain-driven-design domain-events

【解决方案1】：

我们在这里讨论的是 DDD。所以我要问的第一个问题是您希望通过代码反映的业务中发生了什么。

企业决定对整个产品系列“调整价格”10% 的可能性很小。这与定价策略有关。哪个是产品或产品类别的个体。所以，我会先询问商家。

接下来，如果在基础业务中，您有一些专门的人员或部门来处理定价，这将为您提供上下文边界。最有可能的定价是与库存（列出产品）分开的域。很可能存在一些基本价格，即产品的主要成本。然后有一些额外的成本，一些利润将形成利润。那么，通过“调整”价格——你要达到什么目的？这是否意味着主要成本发生了变化？还是保证金改变了？或者一些营销活动结束了？弄清楚 - 你会得到你问题的答案。您将能够从中派生事件名称。

总结一下：存储/解雇/提出/调度与业务相关的事件。

【讨论】：

我故意省略了一些细节，但我会解释一下。在我们的业务中，我们想要调整一组选定的项目或客户项目。不用太深入，我们的定价调整汇总，有一个项目调整和客户调整的列表。这本质上就是我们如何确定我们需要调整什么（哪些项目和项目调整）现在我们看到所有这些都在“目录”有界上下文 atm 中，因为它与我们为客户列出的价格有关（只是抛出那个，所以你知道有多个边界）
1.现实世界最终始终如一地工作。在商品“知道”调整后的价格之前，应该可以显示之前的价格。您可以通过技术将这种“承认差距”缩小到最低限度，但从业务角度来看应该完全没问题。
2.如果一致性是强制性的——那么一个事件应该是一个事务。这也意味着一致性边界不应跨越两个不同的聚合。您需要做出设计决定。是否有两个最终一致的聚合或有一个立即一致的聚合。我倾向于使用更少、更复杂和更长寿的聚合体，而不是大量寿命较短的聚合体。想象一下医院病人的记录簿。每个患者（物理记录簿）有一个汇总，而不是每次就诊。或者每个教堂都有一本度量书，而不是每个人。
在给定百分比调整时，该项目必须计算调整价格。我更新了问题，更好地描述了我当前的实现
Item 和 PriceAdjustment 之间的循环依赖看起来很糟糕。他们倾听彼此的事件。由于在 PriceAdjustment 中调整价格的决定是制定的，因此执行此决定的第三部分逻辑可能负责：在项目上调用 AdjustPrice，确保它成功，然后更新 PriceAdjustment 的状态。