我是eventourced应用程序的新手，从一开始我就面临一个我不确定如何解决的问题。
我在电子商务工作，我总是尝试向我的聚合传达有意义的事件，例如PriceIncreasedEvent，ProductDeactivatedEvent，OutOfStockEvent等
但很多时候我只想用我的聚合做一个简单的“CRUD”风格。例如，用户可以更改产品图像，但我不想将我的聚合与ImageUploadedEvent事件混淆，因为它不是它应该处理的域的一部分。
我想要做的只是在数据库中设置新的图像路径。但由于“预测”应该是一次性的，我不能这样做，因为我会丢失信息。
这通常发生在其他类型的编辑数据中，例如某些内容的标题/名称。我不想创建一个事件TitleChanged，我知道这是一个代码气味，对TitleChanged的域名无关紧要。我只是想改变它。
也许事件采购是一个坏主意？你们是如何处理这种情况的呢？
答案 0 :(得分：2)
要考虑阅读的内容是来自域驱动设计的上下文映射。
我同意VoiceOfUnreason的说法，你可以将传统的CRUD与系统中的事件采购完全混合 - 而且可能应该这样。
让我大吃一惊的是理解域中的相同概念可以存在并解决不同环境中的不同问题。事件采购可以适用于对一个部件进行建模，而CRUD可能更适合另一个部件。您可以将其视为解决整体不同部分的两个独立系统。
示例可以是具有您的PriceIncreasedEvent等的产品，但也可以有一个基于CRUD的不同的产品实体 - 包含基本数据，例如产品标题和图像，这些都解决了那个问题。关键在于跟踪状态变化以及变更（事件）本身对您的域名是否重要。
我通常在查询服务（CQRS样式）中将它们合并在一起，并使用UUID将聚合与CRUD实体一起键入。
希望有所帮助！
答案 1 :(得分：1)
也许事件采购是一个坏主意？
赛事采购是一个高尔夫俱乐部，而不是台球杆 - 每次投篮都不需要使用它。
特别是，如果您不需要在过去的某个任意点恢复模型的能力，事件采购可能不会最终完全消除。
例如，用户可以更改产品图像，但我不想在ImageUploadedEvent事件中弄乱我的聚合，因为它不是它应该处理的域的一部分。
正确 - 并且您不会在产品图像的内容周围拥有大量复杂的域逻辑，甚至不能使用URL或文件路径的拼写来访问图像。它只是一大堆不透明的数据。
事件采购对于这种情况的意义不如贵公司获得竞争优势的复杂业务能力。
好消息：没有规则说你必须在任何地方使用事件采购。你可以挑选。
（但是，尝试使用一个事务来更新两个不同的数据库时会有一些复杂的情况。）