私は DDD および CQRS パターンの初心者であり、ドメイン エンティティを検証する方法について意見を求めたいと思います。一般的な例の Order->OrderLine を使用します。ここで、Order は AR です。
Aggregate 内のビジネス ルールの検証は、一貫性の問題のために AR によって行われます。Aggregate of Order 以外のデータを必要とするビジネス ルールを検証するにはどうすればよいですか?
私はCQRSアプローチも使用しています.ReadModelを使用して、ビジネスルールの検証に必要なデータを取得することは悪い選択肢ではないと思います...どう思いますか?
私の CQRS の経験から、私は ReadModel を結果整合性があると関連付けています。そのため、ReadModel がシステムの現在の状態を表すことに 100% の自信を持っているわけではありません。これは、ReadModel を配布してレプリケートする場合に、より多くの場合に当てはまります。
ReadModel を使用して、アプリケーションに送信される無効なコマンドの数を制限したいだけです。
単一の集約/エンティティ/値オブジェクトの境界外にあるドメイン ロジックをカプセル化するために使用できるドメイン サービスについて考え始めたいと思われます。
David がここでImplement Domain Services as Extension Methods for the repository を指摘しているように、Jimmy Bogard にはhttp://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/という定義があります。
はい、コマンドの検証に読み取りモデルを使用します。私はこれを「コマンド コンテキスト」と呼んでいます。これは、どのコマンドが有効か無効かに基づいた世界の現在の状態です。CQRS では、この世界の現在の状態は読み取りモデルで表されます。ユーザーはそれに基づいて、どのコマンドを発行するかを決定します。
ユーザーの決定を導くさまざまな方法を検討して、無効なコマンドを発行しないようにすることもできます (ユーザー名が一意でない場合は事前に警告するなど)。