我想知道域事件的粒度应该是多少？
例如，我有一些简单的事情，比如在个人资料页面上更改名字、第二个名字和电子邮件地址。我应该有 3 个不同的域事件还是只有一个？
当我添加一个新特性时，通过粗粒度的域事件，我必须创建一个新版本的事件，所以我必须添加一个新的事件类型，或者将事件版本存储在事件存储中。通过细粒度的领域事件，我没有这些问题，但是我有太多的小类。您认为，在这种情况下，最佳做法是什么？
【问题讨论】：
标签： domain-driven-design cqrs event-sourcing
我可以同意 MikeSW 的回答，但是在建模过程中应用 SRP，最终可以得到小班，这完全不是问题。
根据Greg Young，领域事件应该始终表达用户从业务角度所做的事情。例如，如果用户有 2 个理由更改她的电话号码 PhoneNumberChanged，并且从业务角度来看，此信息可能很重要，那么我们应该创建 2 个事件类型 PhoneNumberMigrated、PhoneNumberCorrected 以在技术上存储相同的数据。这显然违反了 DRY，但这不是问题，因为 SRP 在这些情况下可以覆盖 DRY，就像它通过在多个有界上下文之间共享聚合及其属性（最常见的是聚合 id）一样。
在我的例子中：
我有一些简单的事情，比如更改名字， 个人资料页面上的 secondName 和电子邮件地址。
我们应该问以下问题：用户为什么要这样，从我们业务的角度来看有什么重要性？
好吧，如果我们有约会代理服务，那么记录离婚可能具有商业重要性。所以如果这个信息真的很重要，那么我们应该把它放到领域模型中，并创建一个UserProbablyDivorced 事件。如果它们都不重要，那么我们可以简单地说，她只是想更改她的个人资料页面，我们不在乎为什么，所以我认为在这种情况下UserProfileChanged 或UserSecondNameChanged 事件都可以接受。
领域事件可以与命令成 1:1 和 1:n 关系。他们以 1:1 的关系命名通常与命令相同，但使用过去时。例如ChangeUserProfile -> UserProfileChanged。通过 1:n 关系，我们通常将命令所代表的行为分解为一系列较小的域事件。
因此，总而言之，领域事件的粒度应该由领域开发人员决定，但它应该受到业务角度的明显影响，而不仅仅是从数据模式建模的角度。但我认为这很明显，因为我们正在为业务建模，而不仅仅是数据结构。
【讨论】：
很多类有什么问题？真的，为什么这么多开发者害怕有太多的类？您可以根据需要定义尽可能多的类。
域事件表明域以某种方式发生了变化。它应该包含所有相关信息，并且应该考虑到事件也是 DTO 的事实。您想要明确的事件，但由开发人员决定事件的粒度或通用性。
大小不是问题，但是如果您的事件“权重”为 1 MB，则可能有问题。而且类的数量不是领域事件设计的标准。
【讨论】：