Events 聚合之间的DDD事件示例

我有两个问题

项目和价格调整

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

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

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

我的问题是，清单价格的更新和项目调整的标记是如何组成事件的

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

这是正确的解决方案吗

• 调用项目上的函数（如AdjustListPrice），并传入价格调整信息（如要调整的id和百分比）
• 然后引发一个事件，如ItemListPriceAdjusted，让价格调整侦听，以便它可以将调整标记为完成，并引发另一个事件，如itemPriceadjustmentCompleted

如果这是正确的方法，那么新计算的标价应该添加到ItemListPriceAdjusted price中，还是只添加调整百分比，然后在应用/读取聚合时进行计算

谢谢

编辑：

我目前的选择是，在处理价格调整时，它将经历每个项目的调整

它将找到目标项并调用函数 AdjustPrice（Guid priceAdjustmentId，十进制adjustmentPercentage）

这将计算该项目的新标价，该项目将发出一个ItemPriceAdjusted事件，其中包含价格调整id、和新标价

---

然后，价格调整将侦听这些事件，并将相关的项目调整标记为完成，进而发出其自己的项目调整完成事件。所以我要问的第一个问题是，您希望通过代码反映业务中发生了什么

一家企业不太可能决定将整个产品组合的价格“调整”10%。这与定价策略有关。这是一种产品或一类产品的个体。所以，我首先要问一下生意

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

---

总而言之：存储/火灾/引发/发送与业务相关的事件。

我故意省略了一些细节，但我会解释一下。在我们的业务中，我们希望调整一组选定的项目或客户项目。在不深入讨论的情况下，我们的定价调整汇总有一个项目调整和客户调整列表。这基本上就是我们确定需要调整的内容（哪些项目和哪些项目）的方式，现在我们看到所有这些都在“目录”范围内，因为这与我们为客户列出的价格有关（仅此而已，你知道存在多个边界）1。现实世界的运作最终完全一致。在商品“知道”调整后的价格之前，可以显示以前的价格。您可以通过技术手段将“认知差距”降至最低，但从业务角度来看，这应该是完全可以的。如果一致性是强制性的，那么事件应该是事务。这也意味着一致性边界不应跨越两个不同的聚合。你要做一个设计决定。无论是有两个最终一致的聚合，还是有一个立即一致的聚合。我倾向于数量更少、更复杂、寿命更长的集合，而不是数量更多的寿命更短的集合。想象一个医院病人的病历簿。每个患者（体检记录簿）只有一个汇总，而不是每次就诊。或者每个教堂有一本米制书，而不是每个人。当给出一个百分比进行调整时，该项目必须计算出调整价格。我更新了这个问题，更好地描述了我当前的实现项目和价格调整之间的周期性依赖看起来很糟糕。他们互相倾听对方的事件。由于在PriceAdjustment中调整价格的决定是虚构的，因此执行该决定可能是第三条逻辑的责任：对某个项目调用AdjustPrice，确保它成功，然后更新PriceAdjustment的状态。