我的问题与CQRS(命令和查询责任隔离)和构建阅读模型(视图)的机制有关.据我所知,读模型是由事件处理程序构建的.这些处理程序(也称为非规范化程序)接收域事件并使用这些事件来构建不同的数据视图.
特定事件包含有关域模型中所做更改的信息.我认为这些信息在某些情况下不足以构建视图 - 即没有更改字段,在此类事件中没有更改实体等.
所以我的问题是:
是否允许负责构建读取模型的非规范化器不仅访问事件,还允许:
您对事件处理程序(非规范化程序)的允许依赖关系有何看法？
编辑:刚刚在上面的问题中添加了简单示例:
假设以下模型:
AR:ProductOffering*名称*描述*类别*价格
AR:客户*名称*类型*方法:buyProduct(productOffering),发出ProductPurchasedByCustomer事件
entity:ProductInstance*customer*productOffering
事件:ProductPurchasedByCustomer*customerId*productOfferingId
查看:ProductInventoryView*customerId*productOfferingId*customerType*productOfferingName*productOfferingCategory*price
如何仅使用ProductPurchasedByCustomer事件构建ProductInventoryView？如何编写denormalizer以查看有关customerType,productOfferingName等的信息？我应该从不同的视图中查找有关customerType和productOfferingName的其他信息吗？
如果事件消费者需要更多信息,那么事件生成者可以提供所需的信息,尽管它没有改变.不应将事件源视为ORM.请注意,关于如何获取信息,事情可能会变得棘手,但不要让事情复杂化(但).如果事件未提供事件处理程序,则事件处理程序可以使用读取模型的状态(数据).但这样做需要您知道是否可以使用哪些数据.它需要您将时间与数据相结合.消息/事件很可能无序处理.因此,在事件中提供与事件相关的信息要容易得多.在做任何其他事情之前尝试这样做.不要尝试从特定于您的阅读模型的事件处理程序访问您的域,这只是讨厌的耦合.最后一点,聚合可以从其他聚合中复制数据,以提供事件中所需的数据.请注意,从那时起,您必须开始考虑如何在首先复制数据的聚合中保留新数据.可能会让你更困惑......
据我的理解：
更改事件中直接引用的实体？
不
更改了聚合根以及与此聚合相关的任何实体？
不
从域存储库获取的任何实体？
不
任何与事件无关的报告
不
更改事件中直接引用的实体的实体报告？
是的
更改了聚合根报告以及与事件中引用的聚合相关的任何实体报告？
是的
因为反规范化程序应该对域存储库一无所知，并且仅更新相关报告。
如果报告看起来不相关但必须更新，那就是代码味道 - 可能您设计的模型/报告不正确。