我最近在Greg Young EventStore上建立了一个应用程序作为我的存在层，我一直在思考我应该允许一个事件有多大？
例如，我有一个包含以下字段的英国地址汇总
UK_Address
-BuildingName
-Street
-Locality
-Town
-Postcode
现在我正在使用React / Redux构建UI，并且正在考虑是否应该创建一个包含所有上述字段的FAT addressUpdated事件？
或者我应该为每个不同的字段创建一个事件？并在客户端内批量处理它们直到Save事件被触发？ buildingNameUpdated事件，streetUpdated事件，localityUpdated事件。
我不确定答案是否为黑白问我是否已经问过我真正想知道的是你可以用什么条件/约束做出决定？
答案 0 :(得分：3)
我应该为每个不同的字段创建一个事件吗？
没有。您的事件的表示是API的一部分 - 因此您希望使用在业务层面有意义的拼写，而不是在实现层面。
现在我正在使用React / Redux构建UI，并且我在考虑是否应该创建一个包含所有上述字段的FAT updateAddress事件？
您无需约束发送到UI的数据以匹配持久性存储中的数据。 UI只是读取模型的缓存表示;表示没有理由需要与事件存储中的表单形式相同。
考虑React模型本身 - 您的代码对数据的“内存”表示进行更改，然后库计算新DOM并替换它，从而导致浏览器更新其视图，转动会导致屏幕上的像素发生变化。
因此从商店中获取一个胖事件，并将其分解为UI的字段级事件就可以了。从商店中获取多个事件并将它们聚合到UI的单个消息中也很好。从事件存储中获取事件并将其转换为UI将识别的拼写也很好。
对于保持需要保持一致的字段的Arien答案，您有什么评论吗？那么无论你的snapshop什么时候世界的当前状态都处于有效状态？
我不相信这是有道理的，而且我不确定这是否可能。
没有意义，因为“有效状态”只是写模型的关注点;事件是已经发生的事情，它来不及投票决定它们是否有效。例如，如果使用新的不变量部署新模型，则仍需要尊重之前发生的事件的历史记录。因此，您可以为该新模型构建快照，但快照可能不是“有效”。太糟糕了。
鉴于此，我不认为有必要担心提交中的每个单独事件是否使快照处于有效状态。
特别是，如果特定交易涉及多个实体，则域语言很可能会为每个实体建议一个事件（我们“借记现金”和“应收信用账户”）。当然，实体本身能够彼此独立地改变 - 它是维持平衡的聚合。
答案 1 :(得分：1)
当这些数据必须彼此一致时，您必须在一个事件中将信息捆绑在一起。
因此，当您更新地址的一个字段时，您可能会收到不需要的地址。 当客户端由于最终的一致性而未在特定时间处理所有事件时，就会发生这种情况。
实施例： 将地址（City = 1，Street = 1，Housenumber = 1）更改为（City = 2，Street = 2，Housenumber = 2）
当您使用3个事件执行此操作并且在阅读时刚刚处理了一个事件时，您可以获得以下地址:(城市= 2 ，街道= 1 ， Housenumber = <强> 1 ）。
答案 2 :(得分：0)
如果感到困惑，请尝试更易于实施的解决方案。我想＆＃34; FAT＆＃34;事件会更容易：你最终会花更少的时间来实现/调试/支持。
它通常被称为YAGNI-KISS-Occam的Razor原则。
答案 3 :(得分：0)
从理论上讲，我发现将您的命令和事件反映出用户忠于DDD的意图是一个很好的经验法则。您可以在这里找到关于事件粒度的优缺点的良好解释：https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-you-about-event-sourcing-6afc23c69e9a