问题标签 [domain-events]

我一直在研究结合领域事件的领域驱动设计。我真的很喜欢这些事件提供的关注点分离。我遇到了持久化域对象和引发域事件的顺序问题。我想在域对象中引发事件，但我希望它们对持久性无知。

我ShoppingCartService用这个Checkout方法创建了一个基本的：

在此示例中，构造函数Order将引发OrderCreated可由某些处理程序处理的事件。但是，我不希望在实体尚未持久化或持久化失败时引发这些事件。

为了解决这个问题，我想出了几个解决方案：

1. 在服务中引发事件：

我可以在服务中引发事件，而不是在域对象中引发事件。在这种情况下，该Checkout方法将引发OrderCreated事件。这种方法的缺点之一是，通过查看Order域对象，并不清楚哪些事件是由哪些方法引发的。此外，开发人员必须记住在其他地方创建订单时引发事件。感觉不对。

另一种选择是将域事件排队并在持久化成功时引发它们。这可以通过以下using语句来实现，例如：

该QueueEvents<T>方法将设置一个布尔值，true并且该DomainEvents.Raise<T>方法会将事件排队而不是直接执行它。在 dispose 的回调中QueueEvent<T>，队列中的事件被执行，以确保持久化已经发生。这看起来相当棘手，它需要服务知道在域对象中引发了哪个事件。在我提供的示例中，它也只支持引发一种类型的事件，但是，这可以解决。

我可以使用域事件来持久化对象。这似乎没问题，除了持久化对象的事件处理程序应该首先执行，但是我在某处读到域事件不应该依赖于特定的执行顺序。也许这不是那么重要，并且域事件可以以某种方式知道处理程序应该执行的顺序。例如：假设我有一个定义域事件处理程序的接口，实现将如下所示：

当我也想处理持久使用事件处理程序时，我会创建另一个处理程序，从同一接口派生：

现在NotifyCustomer行为取决于保存在数据库中的顺序，因此PersistOrder事件处理程序应该首先执行。这些处理程序引入一个属性（例如，指示其执行顺序）是否可以接受？该方法的实现快照DomainEvents.Raise<OrderCreated>()：

I'm currently trying to find a way to map from one object to another where the first one is a domain model and the other one is an object that represents the same thing, but for a completely different use. A simple example:

Question

I've now received libObj (that is not mine) back with additional information. I would like to invoke a domain event now, but another service that listens for a certain domain event doesn't know the type 3rdPartyLibObj, he only knows MyDevice. How can I now map from 3rdPartyLibObj to MyDevice if they represent the same thing but look different? And if I want to keep MyDevice during the time I wait for the DeviceOnlineEvent, how should I reference it in my dictionary to keep MyDevice and 3rdPartyLibObj in context?

Like this?:

可用于在接收 BCcross-Bounded Context (BC) communication中创建的选项或任何最佳实践方法是什么？BC 在同一个 LAN 中，但在不同的服务器等上。理想情况下，每个 BC 中应该有一个端点，可以根据需要通过 DI 实例化正确的事件处理程序，而不是每个事件/事件处理程序有一个侦听器。Domain EventsDependency Injection (DI)Event Handlers

使用 DI 和本地事件处理程序，像这个简单的例子一样简单，只需很少的努力，但是一旦你在其他服务器上使用 http、tcp、消息队列等。它需要更多的努力和/或库来简化管道。

这适用于 C# .NET 环境。

我已经按照Udi Dahan 的领域事件 - 拯救文章中的规定实现了领域事件。

据我了解，域事件可以与引发它的线程异步运行（通常来自域模型或服务）。

不需要任何类型的“共享”工作单元或存储库实现，也不需要事务一致性。

问题：为什么 Udi 没有在单独的线程中实现域事件的处理？

例如，我添加了一个Task异步处理事件的创建：

是否有任何可能由此产生的多线程问题？

编辑： 请注意，虽然这些域事件是轻量级的，但它们仍将在 IIS 上运行，因为这是一个 MVC Web 项目。

在 C# 中，我有一个场景，其中至少在 2 个地方引发了不同的域事件，我希望一个处理程序使用相同的代码来处理它们（其他侦听器可能执行特定于事件的代码）。使用以下模式的处理程序；

那么用同一个 Handler 处理多个 Event 的最佳方式是什么？谢谢

考虑到领域事件模式和这篇文章，为什么人们建议每个事务模型保留一个聚合？当一个聚合可以改变另一个聚合的状态时，有很好的例子。即使通过删除聚合（或更改其身份）也会导致更改引用它的其他聚合的状态。有人说每个聚合保留一个事务有助于可伸缩性（每个服务器保留一个聚合）。但是这种思维方式不是打破了 DDD 的基本特征：技术不可知论吗？

因此，根据上面的陈述和您的经验，设计聚合、领域事件是否会导致其他聚合发生变化，这将导致每个交易有 2 个或更多聚合（例如：下新订单时）有 100 个项目将客户的状态从正常更改为 VIP )？

领域事件应该根据事件类，还是类和主题来分派？

例如，我有以下事件：

还有一个活动经理，

Udi Dahan提出事件是一流的对象，我喜欢这样。有一个 UserRegisteredEvent对象，一个 OrderComplete对象。我的问题是，类型本身是否绑定到事件处理程序？例如，我应该只将事件对象传递给发布方法吗？

这意味着每个处理程序都绑定到一个类类型，这似乎是有限的。虽然 YAGNI 可能是真的，但以下内容是否更强大：

其中事件主题是处理程序绑定的内容。这样，处理程序可以从继承中受益。如果类型安全或通用语言的使用是一个问题，可以这样做：

这只是较长发布版本的一种简短方法。这让我有点恼火，因为这意味着必须为每个新事件更改类，这似乎是不必要的（实际上，如果使用上述方法，则没有必要）。

虽然我只看到事件作为没有主题的类发布，但这是限制性的，还是有人遇到过这个问题？

我有两个聚合根... AR1 和 AR2。AR1 拥有对 AR2 实例的引用 (ID) 集合。在其中一个 AR1 方法中，会引发域事件以更新 AR2 实例的集合。使用此处提到的技术在事务完成后引发域事件：http ://www.jayway.com/2013/06/20/dont-publish-domain-events-return-them一切都按预期工作。

我的问题是：我从域事件调用以更新 AR2 的方法当前是公共的（不能是内部的），因为域事件正在我的应用程序服务层中执行（与我的业务逻辑层不同的程序集）。我只希望这个方法由域事件执行，而不是别的。

我该怎么做呢？

我想在事务完成后发布域事件。所以我在这里关注了这篇文章： http ://www.jayway.com/2013/06/20/dont-publish-domain-events-return-them/并且还看了这篇 SO 帖子：我应该通过一个存储库到触发事件的域方法

有道理......但我对如何将接口集合解析为具体类型感到困惑。例如，在 IEvent 的集合中可能有 2-3 种不同类型的事件。如何确定添加了哪个事件来触发正确的处理程序？

我一直在学习CQRS / ES。在查看小型示例项目时，我经常看到改变实体状态的事件。例如，如果我们查看Order 聚合根：

当OrderLineAddedEvent应用它时，它会Order通过添加新的订单行来改变。但我不明白这些事情：

• 如果这是一种正确的方法，那么所做的更改如何持续存在？
• 或者我应该以某种方式将事件发布到相应的处理程序Order？我如何在技术上实现这一点？我应该使用服务总线来传输事件吗？