Oop 如何在CQR中建模复杂的查询类

如何对查询类CQR进行建模，因为数据是从不同的地方累积而来的，然后在这些数据之上运行业务逻辑。目前，我们有代码来提取Manager类中所需的数据和域模型中的业务逻辑。有更好的办法吗。高层建议会有所帮助。层次结构是webapi Controller->Manager->DomainModel |->获取所需数据的基础结构

听起来你只是在做CQR的C部分，而不是Q。在CQR中有两个数据模型，一个是通过命令更新的写模型，另一个是定制的，仅用于显示读取模型。当命令更改数据时，它会从写入模型加载包含业务规则的完整聚合，进行适当的更改并保存。然后，它通常通过发送消息请求读取模型的更新

读取模型是为特定目标UI页面自定义构建的表的集合。数据重复无处不在。其思想是读取应该非常快，因为它们只是读取表中的select*查询

---

如果您实现了一个read模型，那么您的问题就没有意义了，因为没有复杂的查询类。如果您尚未实现CQR，那么一般的建议将适用，例如创建存储库以包含查询等。

一般来说，从命令生成的写模型不会镜像从查询获取的读模型

写模型聚合根用于确保域的一致性和不变性，而读模型主要用于构建UI和/或API

如果你为一个博客设计了一个简单的域，你可能会有一篇博文聚合、博文摘要、博文详细信息甚至一篇简单的博文

两者的名称相似，但使用环境不同

您的聚合可能仅通过引用id引用其作者，而您的读取模型可能是一个扁平的预构建模型，包含UI所需的所有必要信息

---

您最终得到了两个模型，其中您的聚合甚至没有公开任何getter，这就是读取模型的目的。

Ah-采用cookie模板体系结构而不了解其含义并评估其是否满足应用程序的要求的危险…您的实际使用情况是什么？我们有内存缓存，DB和外部HTTP API通常作为数据源。对于任何搜索查询，我们必须查询这些源，然后在其上运行业务逻辑，例如，过滤，然后返回数据。