每个 属性 应该有一个更新事件，还是每个具有事件源的实体都有一个更新事件？
Should there be an Update event per Property or an Update event per Entity with Event Sourcing?
我目前正在开发 CMMS 软件。这些软件包中的大多数都有某种方式来管理您的库存，能够创建采购订单以购买更多库存等。
我们系统的一部分与事件溯源完美配合，因为有明确定义的事件。但也有一堆附加数据与整个过程几乎完全无关，只是供公司日后报告使用。
例如，采购订单可能附加了一个部门。我们不会在采购订单的任何阶段使用该部门，但一家公司可能会出现并想要 'How much money has each department spent' 的报告。另一方面，另一家公司可能是如此 small/specialized 他们甚至没有单独的部门，所以它不关心它。
这只是 1 个示例，但可以有相当多的字段（每个实体 5-10 个）。在这种情况下，是不是只用一个涵盖所有这些字段的 'PurchaseOrderUpdated' 事件更好？还是认为像 'PurchaseOrderDepartmentChanged' 这样的单独更新事件更好？
我个人认为每个 属性 应该有一个事件，但我认为我团队的其他人会抱怨必须设置那么多事件。
听起来您可能混淆了两种不同的方法。
事件源系统中的事件描述了已经发生的状态变化。这通常由向（通常）聚合根发出的命令触发。这些域对象的一个关键特征是它们没有任何 public 属性。因此，为每个 属性 创建一个 'Update' 是没有意义的。这是一篇博客 post，其中讨论了事件是如何命名和使用的：
6 Code Smells with your CQRA Events - and how to avoid them
关于事件的负载。我发现确保事件包含丰富的数据更好。进行事件溯源的一个关键价值是能够创建您在最初构建系统时没有考虑过的新读取模型。或者正如您正确指出的那样，为企业创建宝贵的报告。恕我直言，制作丰富的事件，其中包括上下文信息以及有关状态更改的关键信息。
考虑事件的更好方法是将它们视为事务边界。因此，如果默认情况下您有可能更新几个字段，则您不需要发出多个事件。对于这种基于事件的思维，事件建模有助于与组织的其他部门进行沟通：https://eventmodeling.org/posts/what-is-event-modeling/
我目前正在开发 CMMS 软件。这些软件包中的大多数都有某种方式来管理您的库存，能够创建采购订单以购买更多库存等。
我们系统的一部分与事件溯源完美配合，因为有明确定义的事件。但也有一堆附加数据与整个过程几乎完全无关，只是供公司日后报告使用。
例如，采购订单可能附加了一个部门。我们不会在采购订单的任何阶段使用该部门，但一家公司可能会出现并想要 'How much money has each department spent' 的报告。另一方面，另一家公司可能是如此 small/specialized 他们甚至没有单独的部门，所以它不关心它。
这只是 1 个示例，但可以有相当多的字段（每个实体 5-10 个）。在这种情况下，是不是只用一个涵盖所有这些字段的 'PurchaseOrderUpdated' 事件更好？还是认为像 'PurchaseOrderDepartmentChanged' 这样的单独更新事件更好？
我个人认为每个 属性 应该有一个事件，但我认为我团队的其他人会抱怨必须设置那么多事件。
听起来您可能混淆了两种不同的方法。
事件源系统中的事件描述了已经发生的状态变化。这通常由向（通常）聚合根发出的命令触发。这些域对象的一个关键特征是它们没有任何 public 属性。因此，为每个 属性 创建一个 'Update' 是没有意义的。这是一篇博客 post，其中讨论了事件是如何命名和使用的：
6 Code Smells with your CQRA Events - and how to avoid them
关于事件的负载。我发现确保事件包含丰富的数据更好。进行事件溯源的一个关键价值是能够创建您在最初构建系统时没有考虑过的新读取模型。或者正如您正确指出的那样，为企业创建宝贵的报告。恕我直言，制作丰富的事件，其中包括上下文信息以及有关状态更改的关键信息。
考虑事件的更好方法是将它们视为事务边界。因此，如果默认情况下您有可能更新几个字段，则您不需要发出多个事件。对于这种基于事件的思维，事件建模有助于与组织的其他部门进行沟通：https://eventmodeling.org/posts/what-is-event-modeling/