事件风暴：领域事件 "Add to Cart Requested" 是好事还是坏事？
Event Storming : Domain Event "Add to Cart Requested" is Good or Bad practice?
我对事件风暴中的“域事件”（橙色 post-it）有疑问
当我查看一些事件风暴的示例时，我有时会看到如下所示的领域事件：
- “请求取消订单”
- “请求加入购物车”
- “已请求票证”
- “请求创建帐户”
- ...
不过我想知道创建橙色是否是一个好习惯 post- 就像这样，因为它会产生一种重复。
例如：
如果我添加此 post-it :"Create Account Requested"，我还应该 "Account Created "post-它.
如果我添加这个 post-它：“请求添加到购物车”，我也应该添加 “到购物车 post-it.
如果我添加这个 post-it : "Order cancellation Requested", 我也应该 "Order Canceled "post-它.
...
而且我觉得这是一种不好的做法，因为在我看来这会将 post-it 的数量乘以 2。
如果你觉得有橙色很有趣post-就像这样，你能解释一下为什么吗？
如果你认为不是，你能解释一下吗？
感谢您以后的回答。
对某些动作进行明确建模是一件好事。因为这样就很明显，有一个演员参与其中。因此，在实现的系统中应该有一些接口。
这些绝对是事件，因为我们认为它们是已经发生的事情。但它们在某种意义上与事件非常不同，例如。事件溯源（不是风暴）。它们是短暂的，会导致其他事件，我们过去称之为领域事件。那种反映域状态变化的事件。
对我来说，第一组的事件更像是从事件结果到触发交互的意图的垫脚石。
这对于展开流程非常合乎逻辑且非常有用。
更改状态：已添加到购物车。
是什么导致了它？请求加入购物车。
是什么触发了它？客户已将商品添加到购物车。
我会在这种短暂的“事件”上花一张卡片吗？如果它带来额外的清晰度 - 那么肯定是的。因为它有助于专家与开发人员的沟通。如果对于攻击方，尤其是开发人员来说很明显，那么可能不会...因为它增加了噪音而没有增加价值。
与域驱动设计中的所有内容一样，它取决于域。
作为一般规则，域事件是以某种方式改变系统状态的事件，这通常意味着系统中某处至少需要一个命令或查询具有不同的 result/effect 在记录该事件的宇宙中（即存储、广播等）从该事件所在的宇宙中 forgotten/ignored。如果没有受此事件影响的命令或查询，则几乎可以肯定它不是域事件。
因此对于 AddToCartRequested，如果没有任何变化，除非并且直到发生 AddedToCart 事件，那么 AddToCartRequested 不是域事件。但是如果有一个进程有自己的状态用于将商品添加到购物车（例如，这是一个传奇），那么 AddToCartRequested 事件会改变一些状态（例如，如果企业愿意，它可能会保留商品的库存）为了避免必须执行补偿性交易而失去销售）并且是一个真正的领域事件（也有一个 AddToCartRejected 领域事件可能是个好主意 returns 事情大致保持现状).
请注意，关于可观察性（例如 grafana 或其他）是否构成您的域的读取模型有一个有趣的问题：从这个角度来看，尝试将项目添加到购物车的图表将是一个受以下因素影响的查询事件的存在或不存在。 （这种观点导致了一个论点，即几乎所有日志记录 and/or 应用程序级指标实际上都是粗略的域事件...）。
所有这些事件给我的印象是 UI 中的典型步骤。这些似乎是通知，而不是领域事件，我会把它们压缩成一个单一的策略和命令，试图完成最终命令，导致领域实际做某事。
但是，如果所请求的内容对域很重要，则使用“已请求”可能有效，例如请求取消订单导致域批准取消和批准取消订单请求触发订单实际取消并最终取消订单事件
我对事件风暴中的“域事件”（橙色 post-it）有疑问
当我查看一些事件风暴的示例时，我有时会看到如下所示的领域事件：
- “请求取消订单”
- “请求加入购物车”
- “已请求票证”
- “请求创建帐户”
- ...
不过我想知道创建橙色是否是一个好习惯 post- 就像这样，因为它会产生一种重复。 例如：
如果我添加此 post-it :"Create Account Requested"，我还应该 "Account Created "post-它.
如果我添加这个 post-它：“请求添加到购物车”，我也应该添加 “到购物车 post-it.
如果我添加这个 post-it : "Order cancellation Requested", 我也应该 "Order Canceled "post-它.
...
而且我觉得这是一种不好的做法，因为在我看来这会将 post-it 的数量乘以 2。
如果你觉得有橙色很有趣post-就像这样，你能解释一下为什么吗？ 如果你认为不是，你能解释一下吗？
感谢您以后的回答。
对某些动作进行明确建模是一件好事。因为这样就很明显，有一个演员参与其中。因此，在实现的系统中应该有一些接口。
这些绝对是事件，因为我们认为它们是已经发生的事情。但它们在某种意义上与事件非常不同，例如。事件溯源（不是风暴）。它们是短暂的，会导致其他事件，我们过去称之为领域事件。那种反映域状态变化的事件。
对我来说，第一组的事件更像是从事件结果到触发交互的意图的垫脚石。
这对于展开流程非常合乎逻辑且非常有用。
更改状态：已添加到购物车。 是什么导致了它？请求加入购物车。 是什么触发了它？客户已将商品添加到购物车。
我会在这种短暂的“事件”上花一张卡片吗？如果它带来额外的清晰度 - 那么肯定是的。因为它有助于专家与开发人员的沟通。如果对于攻击方，尤其是开发人员来说很明显，那么可能不会...因为它增加了噪音而没有增加价值。
与域驱动设计中的所有内容一样，它取决于域。
作为一般规则，域事件是以某种方式改变系统状态的事件，这通常意味着系统中某处至少需要一个命令或查询具有不同的 result/effect 在记录该事件的宇宙中（即存储、广播等）从该事件所在的宇宙中 forgotten/ignored。如果没有受此事件影响的命令或查询，则几乎可以肯定它不是域事件。
因此对于 AddToCartRequested，如果没有任何变化，除非并且直到发生 AddedToCart 事件，那么 AddToCartRequested 不是域事件。但是如果有一个进程有自己的状态用于将商品添加到购物车（例如，这是一个传奇），那么 AddToCartRequested 事件会改变一些状态（例如，如果企业愿意，它可能会保留商品的库存）为了避免必须执行补偿性交易而失去销售）并且是一个真正的领域事件（也有一个 AddToCartRejected 领域事件可能是个好主意 returns 事情大致保持现状).
请注意，关于可观察性（例如 grafana 或其他）是否构成您的域的读取模型有一个有趣的问题：从这个角度来看，尝试将项目添加到购物车的图表将是一个受以下因素影响的查询事件的存在或不存在。 （这种观点导致了一个论点，即几乎所有日志记录 and/or 应用程序级指标实际上都是粗略的域事件...）。
所有这些事件给我的印象是 UI 中的典型步骤。这些似乎是通知，而不是领域事件，我会把它们压缩成一个单一的策略和命令，试图完成最终命令，导致领域实际做某事。
但是，如果所请求的内容对域很重要，则使用“已请求”可能有效，例如请求取消订单导致域批准取消和批准取消订单请求触发订单实际取消并最终取消订单事件