2011-01-14 10 views
8

私は最近開始しようとしている緑色のフィールドプロジェクトのCQRSとDDDの調査を開始しました。私はUdi Dahan、Greg Young、Mark Nijhof他から多くの資料を勉強しました。これらは本当に非常に役に立ち、私はその概念をよく理解していると思います。しかし、私が自分のドメインにこれ​​らをどのように適用できるかについては、まだまだ疑問が残っています。ルールは、特定の製品の最終的な価格が決まるする -CQRS - シナリオ実行システムをモデル化する方法

私のシステムは、基本的には、複雑なルールエンジンとなります。製品の定義とルールは管理者によってシステムに入力されます。ルールは、年齢ように、事前に定義されたセットからの値を持つことができる特性、例えば「購入の目的」として(再販は、貸し出す)または自由形式の値の所定のセットを使用して管理者が設計されます。

各製品は、基本価格を持っていますし、ルールは基本的に、彼らが適用された場合に基本価格から削除/追加されます。

非常に簡単なサンプルルールは次のようになります。製品Xについては

は、IF(購入目的=再販と年齢> 25)は基本料金に25 $を追加します。

だから製品、ルールベースの価格を定義するシステムを使用するユーザー、管理者、の2種類があります。 what-if UIを介して入力したシナリオに基づいて価格をクエリする他のユーザーが含まれます。

シナリオを実行してもドメインの状態はまったく変更されません。シナリオの実行結果に関心のある外部システム/ユーザーは誰もいません。実行中のユーザー自身です。指定されたシナリオに適用されるルールを実行した後の価格計算の結果。例えば、ユーザは、商品Xを選択し、所定のシナリオの価格、など(購入目的=再販と年齢= 40)を照会するかもしれません。繰り返しますが、この操作でドメインの状態はまったく変更されないため、クエリであると思います。しかし、最終的な価格を計算するためにシナリオ上で動作するルールエンジンがあります。これは、ドメインロジックが実行されていると分類できます。だから - この論理はどこに属しているのですか?これは、読んだモデルからちょうどうまくいくクエリか、シナリオをドメインモデルで実行する必要のあるコマンドを実行していますか?ここでも、ドメイン層がこれらのルールのための場所であると感じますが、シナリオ実行の結果をユーザーに渡すにはどうすればいいですか(このように考えているクエリのように感じます)。あるいは、CQRSはこの問題の正しい解決策ではありませんか?

+0

+1私は聞いたことがない[cqrs](http://blog.fossmo.net/post/Command-and-Query-Responsibility-Segregation-%28CQRS%29.aspx)パターンがある前。ただ、明確にする – k3b

答えて

4

私は自分のドメインでこの正確な問題を抱えていました(電子スケジューリング4ヘルスケア)。基本的に、システムはドメインモデル(書き込み側)を使用して構成されます。これは、ドメイン内のルール、製品、基本価格を定義することになります。ドメインから何が出てくるのですか?イベント、状態の変化、起こったこと、それが起こった理由。今私がしたことは、私のケースでは、医者、手術室、高価な機器のスケジュールに空きスロットを見つける複雑な検索エンジンでは、これらのイベントを別のBounded Contextで消費していました。これは、製品、基本価格、およびルールに関連するイベントを消費し、そのデータの上に乗っているルールエンジンがシナリオに対するユーザーの要求を効率的に処理できるような方法で格納できます。可能。ほとんどの場合、変更(ドメイン)を格納するモデルは、それらのwhat-ifシナリオ(ルールエンジン)を照会するために最適化されたモデルとは異なります。あなたのドメインには、「同じ商品を2回指定することはできません」または「このルールは決して適合しません(年齢: &年齢>」のようなルールが設定されている可能性があります。ドメインは、有効な状態変更のみを許可することに関係しています。これはルールエンジンの関心事ではありません。ドメイン内で定義されているルールエンジンでコンセプト/クラスを再利用したいと思うでしょう。その衝動に抵抗する。彼らが本当に同じ目的を果たすかどうか質問してください。異なる目的のために2回モデリングすることは、汚れていないか、DRYに違反していません。

+0

、クエリは(ほとんどのコマンドやイベントなどの)オブジェクト/メッセージとしてモデル化され、ハンドラがその照会要求を処理し、クエリ応答を発するクエリハンドラベースのアプローチを使用して、何も問題はありません。これは、ルールエンジンのフロントエンドになる可能性があります。 –

+0

あなたの返事をありがとう、イヴ。しかし、私はまだ100%明確ではありません。 ここで私は3つの境界のあるコンテキストを持っていますか? 1 - ドメインモデル(書き込み側管理状態)、2 - シナリオ実行制限付きコンテキスト、3 - UI - 2と3の読み取りモデルは1にスレーブされます。 3つとも独自の永続化メカニズムを持っていますか? 感謝 - カーン。 – KaanK

+0

短い答え:はい。異なる目的を果たす3つの別々のモデル。弾丸だけを噛んでください。 –

0

CQRSは、アプリケーションのクエリ部分にドメインロジックがあってはならないということについては何も述べていません。それが可能で実用的であれば、アプリケーションのすべてのアスペクトやクエリのために別々の非正規化クエリストアを持つことは大丈夫ですが、もちろん必要ありません。要するに

、クエリがどんなに複雑なことの答えを見つける作業、クエリではありません。

関連する問題