【问题标题】：DDD and EDA - Singular vs Plural event names with set-oriented operationsDDD 和 EDA - 具有面向集合操作的单数与复数事件名称
【发布时间】：2022-11-02 11:18:59
【问题描述】：
语境：我正在开发的产品正在从单体架构转向模块化单体架构，并且在实现 DDD 概念的过程中，以及更加事件驱动的架构。
问题：许多操作都是面向集合的（即它们接受一组Items 而不是单个）。据我了解，这违反了“每笔交易一次聚合更改”的聚合规则，但是 Vaughn Vernon 在 IDDD（第 367/368 页）中提到“用户界面方便，允许用户创建批量聚合”（意译）是打破此规则的“公认理由”之一。没有提及相应的事件会是什么样子。
问题：在这种特殊情况下，将所有 ItemCreated 事件批处理到单个 ItemsCreated 事件（复数与单数）中，并将所有单个事件作为有效负载是否正确？
因此，如果用户一次创建 10 个 Items，而不是 10 个 ItemCreated（单数）事件，我将有一个 ItemsCreated（复数）事件，并引用 10 个 Items。
其他说明：我知道领域事件是由聚合发出的，因此那里应该事件发射命令和领域事件之间的 1:1 匹配。我不确定这批事件是否可以在远离聚合的情况下完成。
【问题讨论】：
标签：
events
domain-driven-design
event-driven
【解决方案1】：
我知道领域事件是由聚合发出的，因此事件发出命令和领域事件之间应该有 1:1 的匹配。
有许多人强烈地认为，一项“交易”必然意味着一项“事件”。我和他们中的一些人争论过。它们并不是特别有说服力。但显然我也不是。
1:1 很简单 - 但您必须小心在其他地方为简单而更复杂的情况付费。
在这种特殊情况下，将所有 ItemCreated 事件批处理到单个 ItemsCreated 事件（复数与单数）中，并将所有单个事件作为有效负载是否正确？
它可能是（但我猜它不会是）。
我认为您应该做的是更仔细地研究情况的细微差别——在您正在建模的业务领域内，这真的是一件事，还是恰好在时间上巧合的 10 件不同的事情，因为他们是一起交付的？
是否每个人都关心这个集合中的一个项目，是否一定会关心所有这些项目？
如果您要将“create 10”实现为两个不同的“create 5”，那会要求一个事件吗？两个事件？ 10个事件？
您将这些视为 10 个不同的聚合（而不是其中包含 10 个不同实体的一个聚合）这一事实表明，我们确实有 10 种不同的创建行为是企业关心的。