Question

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

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

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
       });
}

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

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

Answer 1

当然，您可以根据需要自由创建和发布任意数量的事件，但我看不到 (m) 任何好处。

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

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

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

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

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

1 个答案: