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