architecture - 使用域事件更新读取模型不会重复业务逻辑吗？

Question

我目前正在考虑域事件的粒度。据我了解，从命令到域事件的 1:1 关系开始是一个很好的模式，以便域事件表达用户所做的事情。

在我的示例中，有一段旅程(火车或公共(public)汽车)由一系列停靠点组成。这些停靠点中的每一个都分配了一个时间戳，当它将发生时。现在，用户可以取消此旅程，这会导致从旅程的停靠点中删除(简化)所有时间戳。

我要做的是发出一个“JourneyCancelled”事件。

现在，如果有一个读取模型提供旅程的停靠点列表 - 读取模型将如何处理此事件？它可能还会重置旅程的每一站的时间戳，这意味着它会在此处复制逻辑(以及在处理此事件的所有其他读取模型中)。

我对旅程被取消的事实感兴趣，但我也对发生的细节感兴趣。

我在域事件方面做错了什么？

罗尼

Answer 1

As far as I understood it is a good pattern to start with a 1:1 relation from commands to domain events so that a domain event expresses something the user did.

重新学习 - 1:1 很常见，因为许多命令只修改单个实体并且不需要任何补偿操作，但这并不通用。当用户提出更改时，您通常需要多个事件来保持不变性。

您还需要小心“用户所做的事情”。如果您的消息描述的是用户(在现实世界中)所做的事情，那么该消息是一个事件，而不是一个命令。命令是用户要求模型做某事(重要的试金石——模型是否允许拒绝？)。

In my example there is a journey (of a train or a bus) which consists of a sequence of stops. Each of these stops has a timestamp assigned when it is going to happen.

还要记住，“聚合”几乎总是信息资源——不是 Traveler，而是 TravelerProfile。不是旅程，而是预订或行程。

在这种情况下，“什么时候发生”意味着 Schedule 或 Itinerary 作为一个概念，应该在您的模型中明确显示(尚不清楚该事物是聚合的根还是其中的子实体)。

您还需要考虑停靠点(我喜欢 Legs，来自我在旅行软件中的工作)是值(value)，还是具有当前状态的实体。

Now the user may cancel this journey which results in all the timestamps being removed (simplified) from the journey's stops.

提示:在寻求建模建议时，避免简化；良好的建模需要了解约束。

完全不清楚为什么取消旅程应该从时间表中删除时间戳。

试图猜测你想要什么的类比；在航空旅行中，旅行是由腿组成的。如果我们取消行程，我们还想取消支付腿的票，释放座位分配，等等。

所以选择座位分配作为具体例子；取消行程意味着释放座位分配的事实是不变的，因此应该有一个明确的事件宣布座位分配已被取消(如时间戳等)。

因此，跟踪座位分配的读取模型应该监听座位分配事件，并适本地更新座位图(显式)，而不是监听 JourneyCancelled 并推断座位的变化(隐式)。

换句话说，我们通过使事件流更加明确来避免重复业务逻辑的陷阱。请注意我们免费获得的额外解耦:因为读取模型可以监听特定于它关心的实体的事件，我们可以重新设计写入模型中的聚合，而不必担心对读取模型的影响。