在研究领域事件和集成事件时，我发现一些文章倾向于将异步领域事件称为集成事件。
我对领域事件的理解是，这种类型的事件用于通知同一限界上下文内的系统在该限界上下文中发生的事情，而集成事件是用于跨越限界上下文边界的通知的事件，因此集成事件的处理程序可能存在于另一个有界上下文的微服务中。
我一直认为区别在于通知的范围，而不是本质上是同步还是异步。
但是我读了一些文章，其中提到集成事件只是异步域事件，而没有考虑它是否是一个超出有界上下文边界的通知。
下订单后，需要通过电子邮件等渠道通知客户。将使用第三方 API 来执行此操作。下订单时，将引发 OrderRaishedDomainEvent，域事件处理程序将接收此事件并使用第三方发送电子邮件。发送邮件时发生的错误不应干扰其他发生的事情，因此我假设这应该异步发生。那么，OrderRaishedDomainEvent 是否只是一个异步领域事件，而不是一个 IntegrationEvent，因为在有界上下文之外没有消息发生？
所以我的问题是，我是否应该根据同步性来区分领域事件的类型，并将它们视为同步领域事件和异步领域事件，并将集成事件视为一个单独的概念，或者我应该只考虑术语领域事件和集成事件，当领域事件只是同步事件，而集成事件是异步处理事件时？
是的，你没有看错。一些域事件是异步处理的。但是，通过异步处理每个事件，会使域变得更加复杂。因此，对于某些事件，最好同步处理它们，因为这样会更容易管理一致性。
当您想要独立于事件处理程序提交更改时，将应用异步或集成事件。为此，您可以使用异步事件。但是等等，为什么你需要这个？如果在处理命令后在有界上下文中执行某些操作很重要，为什么还要异步处理它呢？
注意：但是，如果您不关心事件是否会成功处理，也许异步事件可以帮助您释放线程并提高性能。
为了实现这种事件分离，我将在应用程序层引入集成事件类（事件参数），并让域事件处理程序或命令处理程序发布它们。领域模型应该只发布其领域事件。
采用这种方法，很明显，领域事件是让外部人员了解领域中发生的事情的方式。应用程序有责任发布适当的集成事件。
注意： 当然，您可以在域层上执行此操作，但我认为它会因集成复杂性而污染您的域层。
总而言之，事件有两种类型
域事件：将在引发命令处理程序的同一事务中处理的事件。 （内部有界上下文）。它表示某项已成功执行，但如果其他聚合不同意，则事务将不会提交。所以实际上命令处理的结果还没有持久化。
集成（异步）事件：将在另一个事务中处理的事件。它们应该由应用层发布。他们说某件事在我的有限环境中发生并成功持续。如果其他人（其他有界上下文或同一有界上下文中的其他聚合）不同意，他们应该发布一个补偿事件来回滚第一个操作。