问题标签 [domain-events]

我正在研究领域事件，并且出于历史原因需要一些关于持久更新实体的建议。我的示例处理用户实体和登录：

因此，在我有这些东西的地方，我想更新用户对象 LastLoginDate 并可能记录用户出于历史原因登录的日期和时间。我的问题是，我会创建我的存储库和上下文的新实例来保存处理程序中的更改还是将某些内容传递给事件？这就是我现在正在努力解决的问题。

我在最近的一个项目中很难实现事件。

我已验证结构映射正在正确扫描组装并添加 EventHandlers

在我曾经从域中触发事件之前。类似的东西Dispatcher.RaiseEvent(new [domainEvent class](x,y,z));

并且该事件将被触发。我不得不改变我现在在集合中收集事件的设计

然后在我将域保存到存储库后提升它

但现在

ObjectFactory.GetAllInstances<IHandle<TEvent>>() 返回 0 个处理程序

如果我注意

ObjectFactory.GetAllInstances<IHandle<DomainEventClass>>() 它正确返回处理程序集合（目前我有 2 个，它显示 2 个计数）

...我假设这与作为类型IDomainEvent 而不是实际类型引发的事件有关，这使得结构映射难以解决它。

我该如何解决这个问题？

问候，

三月

--

编辑1：

我已经确认 struturemap 容器包含从程序集中扫描的所有事件处理程序。

编辑 2

我不知道如何让这个问题引起更多关注。我正在为实现所需结果的解决方案添加赏金。如果问题不清楚，请询问。

基本上我希望ObjectFactory.GetAllInstances<IHandle<TEvent>>()返回处理程序TEventwhere TEventis of Type IDomainEvent。要引发的事件存储在 Collection of 中IDomainEvent，并在保存域（从服务层）之后引发。

我在想应该有某种方法让结构图知道引发的事件IDomainEvent实际上是类型DomainEvent

var eventsToRaise=dealer.EventsToRaise(); 从调试窗口添加信息：

在调度程序窗口中引发事件之后

编辑 3：尽管 eventToRaise 显示为“DealerName Changed”和“DealerCommunicationChanged”
typeof(TEvent) 将 Type 提供为 Domain.IDomainEvent

我猜想是否有可能转换为正确的类型（从 VS 监视窗口获取信息的任何地方）问题可能会得到解决

- - - 结果 - -

两种方法都有效。我将两者都联系到了我团队中的其他 2 名成员，我们认为没有反思的解决方案被选为正确答案。

今天我们将做一个改变实现的测试，看看这个解决方案在解决方案中是否有任何问题。

我赞成基于反射的解决方案，因为它也是正确的答案。

我是 DDD 的新手，我现在正在阅读文章以获取更多信息。其中一篇文章侧重于领域事件 (DE)。例如，发送电子邮件是在执行一段代码时满足某些条件后引发的域事件。

代码示例显示了一种处理域事件的方法，然后是本段

请注意，上述代码将在与常规域工作相同的事务内的同一线程上运行，因此您应避免执行任何阻塞活动，例如使用 SMTP 或 Web 服务。相反，更喜欢使用单向消息传递与执行这些阻塞活动的其他事物进行通信。

我的问题是

1. 这是处理 DE 的普遍问题吗？或者只是提到文章中的解决方案？
2. 如果事务中引发领域事件，系统不会同步处理，应该如何处理？
3. 当我决定序列化这些事件并让调度程序（或任何其他机制）执行它们时，事务回滚时会发生什么？（在文章中事件在事务中执行的代码中引发）谁将取消它们（当它们没有持久化到数据库时）？

谢谢

这篇文章描述了一个名为“领域事件”的伟大模式：http ://www.udidahan.com/2009/06/14/domain-events-salvation/

然而，用户 Andy 在评论 27 中强调了这种模式的一个主要缺陷：如果事务失败，我们不希望执行域事件。因此，我们需要创建某种排队机制。

不幸的是，这听起来会使本应简化系统的技术大大复杂化。

有没有人知道一些关于排队域事件的好例子或讨论，特别是与 NHibernate 很好集成的解决方案？

我有两个聚合根和一个常规实体的简单示例域。 Tenant，UserGroup并且User在这个特定的示例中Tenant和User弥补了两个AggregateRoots。

当从 UI/Service 层接收到命令时，它会到达操作只写域的命令处理程序。

你可以说它User根本不应该是一个AggregateRoot但由于它会被其他人引用，它不能是一个常规实体。（是的？）

这两个 AggregateRoot 需要通信。AUser不能在不属于 a 的情况下被创建UserGroup，它是 的有界上下文中的一个实体Tenant。假设我们可以通过构造函数创建一个用户，因为它是一个简单的约束。User.Create(TenantId, UserGroupId)

它生成一个DomainEvent带有 Date、AggregateVersion 和 AggregateId（用户的）。现在我们来看看模糊的部分。

打开将这个事件提交到存储中，这个事件被广播到总线上（内存，不管）。这就是域的事件处理程序（类似于命令处理程序）捕获用户创建并通知/操作Tenant以UserGroup添加UserId?

我关于解决这个问题的想法是否朝着完全错误的方向发展？

在我见过的所有 CQRS 示例中，域事件会触发对读取模型的更新，但仅此而已。但是，当您希望域事件引起域中的其他更改时呢？

例如，假设您有以下要求：

• 当点击“关闭账户”按钮时，关闭账户
• 账户还清后，关闭账户
• 关闭帐户时，将帐户所有者标记为“特殊”

处理这个问题的最佳方法是什么？

1. 让 Account.Close() 创建一个 AccountClosed 事件并将所有者标记为“特殊”
2. 制作一个将所有者标记为“特殊”的 AccountClosed 处理程序
3. 创建一个提交 MarkOwnerAsSpecial 命令的 AccountClosed 处理程序
4. 使关闭帐户的命令处理程序也将帐户所有者标记为“特殊”

我正在寻找 Udi Dahan 的域事件模式和基础设施的简单 Java 实现，如本文所述。

这很简单，我已经实现了自己的解释，但是我是 Java 新手，不想因为缺乏语言经验而被任何错误所困扰。

我发现的唯一 Java 实现是在Jdon Framework中，但对于我目前的项目来说，它有点过于重量级了。

谢谢！

在文章之后：httpDomainEvents : //www.udidahan.com/2009/06/14/domain-events-salvation/ 我们可以看到实现使用DI容器

进而

我应该将 DI 容器集成到存储域对象的同一个程序集中，还是可以将 DI 容器外部化/抽象掉Container.ResolveAll<Handles<T>>()？（在我以前的经验中，我把所有的DI-related东西都放在里面global.asax.cs）。

从技术上讲，我只熟悉 Ninject DI 容器，但可能会理解这个概念，因此您的建议/插图将受到赞赏。

谢谢！

我正在使用 CQRS 和域事件概念构建具有域模型的应用程序（但没有事件源，只是普通的旧 SQL）。SomethingChanged 类型的事件没有问题。然后我陷入了实现SomethingCreated事件的困境。

当我创建一个映射到具有标识主键的表的实体时，在实体被持久化之前我不知道 Id。实体是持久性无知的，因此当从实体内部发布事件时，Id 是未知的 - 它仅在调用 context.SaveChanges() 后神奇地设置。那么如何/在哪里/何时可以将 Id 放入事件数据中？

我在想：

• 包括对事件中实体的引用。这将在域内工作，但不一定在具有多个自治系统通过事件/消息进行通信的分布式环境中工作。
• 覆盖 SaveChanges() 以某种方式更新排队等待发布的事件。但是事件是不可变的，所以这看起来很脏。
• 摆脱身份字段并使用实体构造函数中生成的 GUID。这可能是最简单的，但可能会影响性能并使其他事情变得更加困难，例如调试或查询（where id = 'B85E62C3-DC56-40C0-852A-49F759AC68FB'、 noMIN等MAX）。这就是我在许多示例应用程序中看到的。
• 混合方法 - 不理会身份，主要将其用于外键和更快的连接，但使用 GUID 作为唯一标识符，我通过它从应用程序的存储库中提取实体。

我正在尝试理解Udi Dahan 说明的关于在特定情况下添加新域实体的域事件模式。

现在通常使用实体创建它们，然后通过存储库添加它们。我想我还会这样做吗？

我的例子是我们通常将资产添加到系统中。像这样：

然而，资产创建是我们希望遵循某些流程的结果。因此，开发人员建议我们不再需要这样做，因为它可以由域事件处理：

现在 create 方法将引发一个事件并由一个 create 事件处理程序处理，该事件处理程序基本上只是将其插入到 repo 中，并做一些其他的事情给创建位置的仓库经理发送电子邮件等。

然而，在资产上创建事件对我来说看起来非常活跃。然而，在领域中，人们谈论正在创建的新资产。所以我们不确定。

想法？