我最近开始调查CQRS和DDD的绿色田野项目，我即将开始。我研究了大量来自Udi Dahan，Greg Young，Mark Nijhof等人的材料。这些非常有用，我想我对这些概念有很好的理解。但是，我仍然有一些问题可以解释如何将这些问题应用到我自己的领域。
我的系统基本上是一个复杂的规则引擎 - 规则将规定某些产品的最终价格。产品定义和规则将由管理员输入系统。规则将由管理员使用预定义的一组属性设计，这些属性可以包含预定义集合中的值，例如'购买目的'（转售，出租）或自由格式值，例如年龄
每个产品都有一个基本价格，如果适用，规则基本上会从基本价格中添加/删除。
一个非常简单的示例规则可能是：
对于产品X，IF（购买目的=转售和年龄> 25）将25美元添加到基本价格。
因此，有两种用户使用系统，管理员，他们定义产品，规则和基本价格;和其他用户根据他们通过假设用户界面输入的方案查询定价。
我的困惑在于：运行场景根本不会改变域的状态，没有其他外部系统/人对场景执行的结果感兴趣但是正在运行的用户他/她自己 - 它返回结果运行给定方案的适用规则后的价格计算。例如，用户可以选择产品X 并查询给定方案的定价，例如（购买目的=转售和年龄= 40）。同样，由于此操作根本不会更改域状态，我想这是一个查询。但是，有一个规则引擎在场景上运行来计算最终价格，我猜这可以被归类为正在运行的域逻辑。那么 - 这个逻辑属于哪里？这是一个仅在读取模型之外工作的查询，还是在运行场景中需要在域模型中运行的命令？再次，感觉域域层是这些规则的地方，但是我如何将场景执行的结果传递给用户（感觉就像是以这种方式思考它的查询）。或者，CQRS不是解决这一特定问题的正确方法吗？
答案 0 :(得分：4)
我在自己的域中遇到了这个问题（e-scheduling 4 healthcare）。基本上，系统使用域模型（写入侧）进行配置。这将定义您域中的规则，产品和基本价格。什么来自域名？事件，状态变化，发生的事情及其发生的原因。现在我所做的就是在不同的Bounded Context中使用这些事件，在我的例子中是一个复杂的搜索引擎，可以在医生，手术室和昂贵设备的时间表中找到空闲的插槽。这可能是您可以采用的路线，消耗您的产品，基本价格和规则相关事件，并以这样的方式存储它们：位于该数据之上的规则引擎可以像处理用户一样高效地处理用户请求。可能。很可能您会发现存储更改的模型（域）与优化的模型不同，以查询假设情景（规则引擎）。您的域名可能会有“您不能两次指定相同产品”或“此规则永远不会匹配（年龄<25＆amp;＆amp;年龄> 25）”等规则。域涉及仅允许有效的状态更改。这不是规则引擎的关注点。您将很想重用在域中定义的规则引擎中的概念/类。抵制那种冲动。问他们是否真的有同样的目的。为了不同的目的对它进行两次建模并不是脏的或是对DRY的违反。
答案 1 :(得分：0)
CQRS没有说明应用程序的查询部分中不应存在域逻辑。如果它可行且实用，那么可以为每个方面或甚至查询应用程序提供单独的非规范化查询存储，但当然没有必要。
简而言之，查询是一个查询，无论找到答案的任务有多复杂。