好的，我很欣赏标题听起来很奇怪。事件应该总是针对已经发生的事情，例如 OrderCreated、ParcelShipped 等。
但是，我想知道是否有人对以下问题有任何想法。
考虑一个对人员及其工作进行建模的 HR 应用程序。为简单起见，一个人可以拥有一堆工作，并且可以在某个日期结束。这个人有一个 EndJob 操作，它需要一个 endDate。
如果 endDate 在未来，领域事件会是什么？
JobEndedEvent（这不是真的）
JobEndDateAddedEvent（这是相当技术性的）
其他有界上下文中的消费者将有兴趣知道作业将要结束，但也可能希望在作业结束时也得到通知。我觉得后者应该是消费者的责任，而不是来源的责任。
欢迎任何想法......谢谢。
好吧，从域的角度来看，您可能正在谈论 JobTerminationScheduledEvent，因为从语言的角度来看，您正在通知其他上下文有关作业结束的调度。
这不是实际情况，日程安排可能会发生变化，您将留给其他上下文，他们将如何处理此类信息。给定的上下文可能认为调度是足够的信息来考虑作业将在给定日期结束。
另一种情况是，当通知发生此类事件时，他们可能希望在日期到来时仔细检查，以确保在采取进一步行动之前没有发生任何变化。
最后，您的上下文实际上是在表达所发生的事情：没有具体内容。您已为该操作定义了一个预定日期，但它尚未发生。
如果 endDate 在未来，领域事件会是什么？
JobCompletionScheduled?
我们现在做出了决定，但它的生效日期是在未来。这在业务线中是一件非常正常的事情，决策本身就是有用的商业智能。
与您的领域专家一起挖掘，并仔细聆听 - 您的领域中可能已经有描述这种情况的词汇。
尽管当您指定某人的工作“即将”结束时会发生一个事件，让我们称之为“jobEndIntentionEvent”，但当人员的工作实际结束时也会发生一个隐式事件 - “jobEndEvent”。
现在，源有界上下文可能不需要引发此“jobEndEvent”来对其自身进行操作。不过，您可能有多个有界上下文，它们只对了解此事件真正感兴趣。那么它应该提高它吗？或者多个其他有界上下文是否都必须打出他们所发的牌——即监听“jobEndIntentionEvent”并实现在他们希望听到的事件（“jobEndEvent”）已经收到时触发的代码？
或者原始有界上下文是否应该很好并为每个人触发这个“集成事件”。
或者，一个更好的解决方案是我们有一个调度有界上下文，它是“jobEndIntentionEvents”和类似的订阅者，并且它知道将它们转换为人们真正关心的真实事件 - “jobEndEvents”。