我将集成事件与域事件分开是否正确？答案

【问题标题】：Am I right in separating integration events from domain events?我将集成事件与域事件分开是否正确？
【发布时间】：2021-02-24 07:21:59
【问题描述】：

我使用事件溯源来存储我的对象。

通过域事件捕获更改，仅包含所需的最少信息，例如

GroupRenamedDomainEvent 
{
   string Name;
}

GroupMemberAddedDomainEvent
{
   int MemberId;
   string Name;
}

但是，在我的应用程序的其他地方，我希望在组一般更新时得到通知。我不想积累或响应一堆更细化且不太有用的领域事件。

我理想的订阅活动是：

GroupUpdatedIntegrationEvent
{
   int Id;
   string Name;
   List<Member> Members;
}

所以我做了以下事情：

更新组聚合。
保存生成的域事件。
使用这些生成的域事件来查看是否触发我的集成事件。

对于上面的示例，这可能如下所示：

var groupAggregate = _groupAggregateRepo.Load(id);

groupAggregate.Rename(“Test”);
groupAggregate.AddMember(1, “John”);

_groupAggregateRepo.Save(groupAggregate);

var domainEvents = groupAggregate.GetEvents();

if (domainEvents.Any())
{
   _integrationEventPublisher.Publish(
       new GroupUpdatedIntegrationEvent
       {
          Id = groupAggregateId,
          Name = groupAggregate.Name,
          Members = groupAggregate.Members
       });
}

这意味着我在整个应用程序中使用的集成事件与我的事件源域事件中使用的数据不相关。

这是一个明智的想法吗？有没有人有更好的选择？我是否误解了这些术语？

【问题讨论】：

标签： event-sourcing event-driven

【解决方案1】：

当然，您可以随意创建和发布任意数量的活动，但我看不到 (m) 有任何好处。

您仍然有耦合：您只是将耦合从一个事件转移到另一个事件。这真的取决于你有多少事件消费者。如果一切都在内存中运行或存储在数据库中。如果您的消费者需要某种重放机制。
您的集成事件会随着时间的推移而增长并占用大量带宽：如果您的群组包含 1000 个成员并且您添加了 5 个新成员，您将触发 5 个始终包含所有成员的集成事件，而不仅仅是小增量。它将使用更多的网络带宽和硬盘空间（如果持久）。
您正在将您的集成事件耦合到您的领域模型。我认为这根本不好。将来您将无法简单地更改 Member 类，因为所有事件消费者都依赖它。解决方案可能是为集成事件使用单独的 MemberDTO 类并编写 MemberToMemberDTO 转换器。
您的事件消费者无法决定他们想要处理哪些更改，因为他们总是只会收到完整的当前状态。实际更改的信息丢失了。

我看到的唯一真正好处是您不必再次编写代码来应用您的领域事件。

总的来说，它看起来有点像 CQRS 中的读取模型。也许这就是你要找的东西？

但这当然取决于。如果您的解决方案符合您的应用程序的需求，那么就可以这样做。制定规则是为了向您指明正确的方向，但当它们妨碍您时（而且您知道自己在做什么），它们也意味着要打破它们。

【讨论】：