尚未发生的事情的领域事件命名答案

【问题标题】：Domain event naming for things that haven't happened yet尚未发生的事情的领域事件命名
【发布时间】：2018-05-10 09:53:35
【问题描述】：

好的，我很欣赏标题听起来很奇怪。一个事件应该总是针对已经发生的事情，例如。 OrderCreated、ParcelShipped 等。

但是，我想知道是否有人对以下问题有任何想法。

考虑一个对人员及其工作进行建模的 HR 应用程序。为简单起见，一个人可以拥有一堆工作，并且可以在某个日期结束。这个人有一个 EndJob 操作，它需要一个 endDate。

如果 endDate 在未来，领域事件会是什么？

JobEndedEvent（这不是真的）

JobEndDateAddedEvent（这很技术性）

其他有界上下文中的消费者会很想知道作业将要结束，但也可能希望在作业结束时也得到通知。我觉得后者应该是消费者的责任，而不是来源的责任。

欢迎提出任何想法...谢谢。

【问题讨论】：

为什么不JobEndingEvent？它表示“结束工作”的过程已经开始，但尚未完成，当它实际发生时将紧跟JobEndedEvent（如果项目被取消或工人被解雇，也可能更早发生表现不佳）
感谢大家的回复。我觉得我可能没有完全表达我的问题的意图。虽然这个名字很有趣。我也有兴趣探索源 BC 是否也应该在工作结束时引发事件。即 2 个事件，JobCompletionSchdule（不是）和 JobEnded（在作业结束时）。

标签： domain-driven-design bounded-contexts domain-events

【解决方案1】：

嗯，从域的角度来看，您可能正在谈论 JobTerminationScheduledEvent，因为从语言的角度来看，您正在通知其他上下文有关作业结束的调度。

这不是实际情况，日程安排可能会发生变化，您将留给其他上下文，他们将如何处理此类信息。给定的上下文可能认为调度是足够的信息来考虑作业将在给定日期结束。

另一种情况，如通知发生此类事件，他们可能希望在日期到来时仔细检查，以确保在采取进一步行动之前没有发生任何变化。

最后，您的上下文实际上是在表达发生的事情，即：没有具体内容。您已为执行此操作定义了预定日期，但尚未执行。

【讨论】：

【解决方案2】：

如果 endDate 在未来，领域事件会是什么？

JobCompletionScheduled?

我们现在做出了决定，但它的生效日期在未来。这在业务线中是一件非常正常的事情，而且决策本身就是有用的商业智能，可以捕捉到。

与您的领域专家一起挖掘，并仔细聆听 - 您的领域中可能已经有描述此案例的词汇。

【讨论】：

【解决方案3】：

虽然当您指定某人的工作“即将结束”时会发生一个事件，让我们称之为“jobEndIntentionEvent”，但当该人的工作实际结束时也会发生一个隐式事件 - “jobEndEvent”。

现在，源有界上下文可能不需要引发此“jobEndEvent”来对其自身进行操作。不过，您可能有多个有界上下文，它们只对了解此事件真正感兴趣。那么它应该提高它吗？或者多个其他有界上下文是否都必须打出他们收到的牌 - 即监听“jobEndIntentionEvent”并实现在他们希望听到的事件（“jobEndEvent”）已经收到时触发的代码？

或者原始有界上下文是否应该很好并为每个人触发这个“集成事件”。

或者一个更好的解决方案是我们有一个调度有界上下文，它是“jobEndIntentionEvents”和类似的订阅者，它知道将它们转换为人们真正关心的真实事件 - “jobEndEvents”。

【讨论】：