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