领域驱动设计和领域事件
我是 DDD 新手，现在正在阅读文章以获取更多信息。其中一篇文章重点介绍了域事件 (DE)。例如，发送电子邮件是执行一段代码时满足某些条件后引发的域事件。
代码示例显示了处理域事件的一种方法，后面是本段
请注意，上述代码将在与常规域工作相同的事务中的同一线程上运行，因此您应该避免执行任何阻止活动，例如使用 SMTP 或 Web 服务。相反，更喜欢使用单向消息传递来与执行这些阻塞活动的其他事物进行通信。
我的问题是
- 这是处理 DE 的普遍问题吗？或者只是关注提到的文章中的解决方案？
- 如果事务中引发了领域事件，系统不会同步处理它们，那么应该如何处理？
- 当我决定序列化这些事件并让调度程序（或任何其他机制）执行它们时，事务回滚时会发生什么？ （在文章中，事件是在事务中执行的代码中引发的）谁将取消它们（当它们没有持久化到数据库时）？
谢谢
I'm new to DDD and I'm reading articles now to get more information. One of the articles focuses on domain events (DE). For example sending email is a domain event raised after some criteria is met while executing piece of code.
Code example shows one way of handling domain events and is followed by this paragraph
Please be aware that the above code will be run on the same thread within the same transaction as the regular domain work so you should avoid performing any blocking activities, like using SMTP or web services. Instead, prefer using one-way messaging to communicate to something else which does those blocking activities.
My questions are
- Is this a general problem in handling DE? Or it is just concern of the solution in mentioned article?
- If domain events are raised in transaction and the system will not handle them synchronously, how should they be handled?
- When I decide to serialize these events and let scheduler (or any other mechanism) execute them, what happens when transaction is rolled back? (in the article event is raised in code executed in transaction) who will cancel them (when they are not persisted to database)?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个普遍的问题时期，不用介意 DDD
一般来说，在任何需要以高性能方式响应的系统中（例如 Web 服务器），任何长时间运行的活动都应该与触发过程异步处理。
这意味着队列。
回滚您的事务 当然，您现在需要额外的机制来处理队列
上的项目无法处理的情况 - 即电子邮件未发送 - 您还需要在触发代码中考虑到这一点 - 具有后续过程依赖于 简而言之，您的排队机制本身应该是事务性的并允许重试，
并且您需要将整个事件链视为一个工作流程。
It's a general problem period never mind DDD
In general, in any system which is required to respond in a performant manner (e.g. a Web Server, any long running activities should be handled asynchronously to the triggering process.
This means queue.
Rolling back your transaction should remove item from the queue.
Of course, you now need additional mechanisms to handle the situation where the item on the queue fails to process - i.e the email isn't sent - you also need to allow for this in your triggering code - having a subsequent process RELY on the earlier process having already occurred is going to cause issues at some point.
In short, your queueing mechanism should itself be transactional and allow for retries and you need to think about the whole chain of events as a workflow.