在实现领域事件时，事件处理程序应该只用于纯粹的领域问题；您会与业务专家讨论的东西，或者它们是否可以被任何对领域模型感兴趣的人使用？
这很可能用一个简单的例子来解释，考虑一个日历应用程序来安排员工的工作。
我们可能有以下领域事件...
AppointmentAdded AppointmentRemoved AppointmentContentChanged AppointmentMoved
我们有这些事件的处理程序，例如，当约会移动到员工工作时间之外的时间时，我们设置了一个警告标志。
当然，有一些应用程序对这些事件感兴趣，例如，当一个约会被添加到日历中时，我们应该将它添加到工作单元中，以便我们以后可以提交更改。
这些应用程序关注点应该是领域事件的消费者，还是我们应该提出并处理单独的系统事件？
在 DDD 解决方案中有两种使用事件的成熟方法。
第一个是基于 Udi Dahan关于事件的文章。如果您还没有阅读它们，我强烈建议您阅读。总之，它说除了正常的 ORM 样式行为之外，您还使用静态类发布事件。因此，您将订单添加到客户的订单集合中并发布事件。因为您的域行为是在事务范围内执行的，所以事件处理程序也是如此。您还可以在那里找到并建议不要手动将对象附加到工作单元。应该通过调用现有聚合根的行为来创建新的聚合根。
There is another option which is promoted by Greg Young. It is based on event sourcing which basically is using events as means of persisting state. In this approach your aggregate roots usually use some infrastructure (e.g. base aggregate root class) to apply events. Apply does invoke an event handler on aggregate root class and publishes this event on a bus (whatever bus implementation you use).
如果您的意思是横切关注点，那么如果您的应用程序逻辑需要它，无论如何您都将被迫使用它。因此它将与其他事件处理代码混合在一起。
但是，如果您在域事件发生时需要做几件独立的事情，那么最好使用单独的事件处理程序（请参阅关注点分离原则）。
顺便说一下，在第一种情况下，尽量避免将域逻辑与事件处理（基础设施）逻辑混合。在调用域方法的事件处理程序中留下基础设施/横切关注点代码。在域对象的方法中移动域代码。