CQRS-如何为场景执行系统建模 [英] CQRS - how to model a scenario execution system

问题描述

我最近开始调查一个即将开始的绿色项目的CQRS和DDD。我研究了Udi Dahan，Greg Young，Mark Nijhof等人的大量材料。这些真的很有帮助，我认为我对这些概念有很好的理解。但是，关于如何将其应用于自己的域，我仍然存在某些疑问。

I recently started investigating CQRS and DDD for a green field project that I'm about to start. I studied a great deal of material from Udi Dahan, Greg Young, Mark Nijhof and others. These were really very helpful and I think I have a good understanding of the concepts. But, there are still certain questions on my mind on how I can apply these to my own domain.

我的系统基本上是一个复杂的规则引擎-其中规则将决定某些产品的最终价格。产品定义和规则将由管理员输入到系统中。管理员将使用一组预定义的属性来设计规则，这些属性可以具有预定义集中的值，例如购买目的（转售，出租），也可以使用自由格式的值（例如年龄。

My system will basically be a complex rules engine - in which rules will dictate the final price of certain products. The product definitions and rules will be entered into the system by administrators. Rules will be designed by administrators using a predefined set of properties that can have values from a predefined set, such as 'Purpose of Purchase' (Resell, Rent out) or free form values, such as Age.

每种产品都有底价，如果适用，则规则基本上会从底价中添加/删除。

Each product will have a base price, and rules will basically add/remove from the base price if they apply.

一个非常简单的示例规则可能是：

A very simple sample rule might be:

对于产品X，IF（购买目的=转售且年龄> 25 ）在基础价格上加上25 $。

因此，有两种使用系统的用户，管理员来定义产品，规则和基础价格;以及其他用户根据通过假设用户界面输入的方案查询定价。

So there are 2 kinds of users that use the system, administrators, who define the products, rules and base prices; and other users that query pricing based on a scenario that they enter in via a what-if UI.

我的困惑是：运行方案不会改变状态对于该域，根本没有其他外部系统/人员对场景执行的结果感兴趣，而是对运行中的用户本人感兴趣-它在运行给定场景的适用规则后返回价格计算的结果。例如，用户可以选择产品X 并查询给定方案的价格，例如（购买目的=转售，年龄= 40）。同样，由于此操作根本不会更改域状态，因此我猜它是一个查询。但是，有一个在场景中运行的规则引擎来计算最终价格，我猜可以将其归类为正在运行的域逻辑。那么-这种逻辑在哪里？这是仅在读取模型上有效的查询，还是在运行方案时需要在域模型中运行的命令？同样，感觉领域层是放置这些规则的地方，但是然后我如何将方案执行的结果传递给用户（感觉像是查询这样思考）。也许CQRS不是解决此特定问题的正确解决方案？

My confusion here is this: running a scenario does not change the state of the domain at all, no other external system/person is interested in the result of the scenario execution but the running user himself/herself - it returns the result of a price calculation after running the applicable rules for the given scenario. For example, user might select Product X and query the pricing for a given scenario, such as (Purchase Purpose = Resell and Age = 40). Again, since this operation does not change the domain state at all, I guess it is a query. But, there is a rule engine operating on the scenario to calculate the final price, which I guess can be categorized as domain logic being run. So - where does this logic belong? Is this a query that just works off of the read model, or is running a scenario a command that needs to be run in the domain model? Again, it feels like the domain layer is the place to be for these rules, but then how do I pass the result of the scenario execution to the user (feels like a query thinking about it this way). Or maybe, CQRS is not the right solution for this particular problem?

推荐答案

我在自己的域中遇到了这个确切的问题（e -安排4个医疗保健）。基本上，系统是使用域模型（写端）配置的。这将是定义您域中的规则，产品和基本价格。域名产生了什么？事件，状态更改，发生的事情以及发生原因。现在，我要做的是在不同的受限环境中使用这些事件，在我的情况下，这是一个复杂的搜索引擎，可以在医生，手术室和昂贵设备的时间表中找到空闲时间。这也可能是一条路线，您可以消耗产品，基本价格和与规则相关的事件，并以某种方式存储它们，以便位于数据之上的规则引擎可以高效地处理用户对方案的请求可能。您很可能会发现存储更改（域）的模型与为查询假设情景而优化的模型（规则引擎）不同。您的域可能会具有诸如您不能两次指定相同的产品或此规则将永远不匹配（年龄小于25岁且年龄大于25岁）之类的规则。该域仅允许有效状态更改。这不是规则引擎的问题。您将很想重用域中定义的规则引擎中的概念/类。抵制这种冲动。质疑它们是否真的达到了相同的目的。为不同的目的对它进行两次建模并不意味着肮脏或违反DRY。

I had this exact issue in my own domain (e-scheduling 4 healthcare). Basically the system is configured using a domain model (write side). This would be defining rules, products and base prices in your domain. What comes out of the domain? Events, state changes, things that happened along with why it happened. Now what I did was consume these events in a different Bounded Context, in my case a complex search engine that finds free slots in the schedules of doctors, operating theaters, and expensive equipment. This could be a route you could take as well, consuming your product, base price, and rule related events and store them in such a way that the rule engine, sitting on top of that data, can handle user requests for scenarios as efficiently as possible. Most likely you'll find out that the model to store changes (domain) differs from the model optimized to query those what-if scenarios (rule engine). Your domain will probably have rules like "you can't specify the same product twice" or "this rule will never be matched (age < 25 && age > 25)". The domain is concerned with only allowing valid state changes. This is not a concern of the rule engine. You'll be tempted to reuse concepts/classes in your rule engine that are defined in the domain. Resist that urge. Question if they really serve the same purpose. Modelling it twice for a different purpose is not dirty or a violation of DRY.

这篇关于CQRS-如何为场景执行系统建模的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！