我一直在研究开发人员在领域驱动设计上设计/构建应用程序的许多常见方法（仍在努力理解整个概念）。我看到的一些例子包括通过事件聚合器使用事件。我喜欢这个概念，因为它确实使应用程序的不同元素/域解耦。
我关心的一个问题是：在出现错误的情况下，如何回滚操作？
例如：
假设我有一个订单应用程序，它必须将订单保存到数据库中，还必须将订单副本以pdf格式保存到CMS中。应用程序触发一个事件，表示已创建新订单，订阅该事件的pdf服务将保存pdf。同时，当将订单更改提交到数据库时，会引发异常。问题是pdf已经保存，但它们不是匹配的数据库记录。
我应该缓存以前处理过的事件，并激发一个新的错误事件，该事件在缓存中查找"撤消"操作吗？为此使用类似命令模式的内容？
或者。。。事件聚合器不是一个好的模式。
编辑
我开始认为，也许事件应该用于不那么"关键任务"的项目，比如电子邮件和日志记录。
我最初的想法是通过使用事件聚合器模式来限制依赖关系。
您希望事件与数据库上的操作在同一事务中提交。
在这种特定的场景中，您可以将事件推送到队列中，该队列将在您的事务中登记，这样，除非聚合被持久化，否则事件永远不会熄灭。这将使创建PDF最终保持一致；如果创建PDF失败，您可以修复问题，并自动重试。
也许你可以从我之前的一篇关于RavenDB和IronMQ最终一致域事件的文章中获得更多灵感。
只有当事件处理程序参与事务时，才可以在事件实际发生（提交）之前处理事件。使事件处理程序具有事务性（例如，将PDF存储在数据库中），或者在事务提交后发布和处理事件。