Domain driven design 每个属性应该有一个更新事件，还是每个实体都应该有一个事件源更新事件？

我目前正在开发CMMS软件。这些软件包中的大多数都有一些管理库存的方法，能够创建采购订单来购买更多的库存，等等

我们系统的一部分与事件来源完美配合，因为有明确定义的事件。但也有一些附加数据与整个过程几乎完全无关，只是公司在以后的报告中使用

例如，采购订单可能附带了一个部门。我们在采购订单的任何阶段都不使用这个部门，但一家公司可能会出现，并希望得到一份“每个部门花了多少钱”的报告。另一方面，另一家公司可能很小/很专业，他们甚至没有单独的部门，所以不关心它

这只是一个例子，但可以有相当数量的字段（每个实体5-10个）。在这种情况下，是否最好只进行一次涵盖所有这些字段的“PurchaseOrderUpdate”事件？还是认为最好有一个单独的更新事件，比如“PurchaseOrderDepartmentChanged”

---

我个人认为每个酒店都应该有一个活动，但我认为我团队的其他成员会抱怨必须设置这么多活动。

听起来你可能混淆了两种不同的方法

事件源系统中的事件描述已发生的状态更改。这通常由向（通常）聚合根发出的命令触发。这些域对象的一个关键特性是它们没有任何公共属性。因此，为每个属性创建“更新”是没有意义的。以下是一篇关于事件名称和使用方式的博客文章：

---

关于事件的有效负载。我发现最好确保事件包含丰富的数据。事件源的一个关键价值是能够创建新的读取模型，而这些模型在最初构建系统时没有考虑到。或者，正如您正确指出的那样，为业务创建宝贵的报告。我会制作丰富的事件，其中包括上下文信息以及有关状态更改的关键信息。

思考事件的更好方法是，它们是事务边界。因此，如果默认情况下有可能更新几个字段，则不需要发出多个事件。对于这种基于事件的思维，事件建模有助于与组织的其他部门进行沟通：

如果这些字段不以任何方式影响业务流程，则意味着不能引入任何业务事件来跟踪它们。您可以将每个聚合的一包此类数据存储在其他地方，通过id引用聚合。