2
CQRSコマンドをどの程度正確に検証し、ドメインオブジェクトに変換する必要がありますか？
あるデータストアにきめ細かなデータを持ち、分析の大きな可能性を提供し、ビジネス価値を向上させ、必要に応じてパフォーマンスを向上させるために非正規化データを含む読み取りを必要とする柔軟性を備えているため、貧乏人のCQRS 1をかなり長い間適応させてきました。 しかし、残念ながら最初から、このタイプのアーキテクチャにビジネスロジックを正確に配置する必要があるという問題に苦労してきました。 私が理解していることから、コマンドは意図を伝える手段であり、ドメイン自体とは関係がありません。これらは基本的にデータ（ダム-必要に応じて）転送オブジェクトです。これは、異なるテクノロジー間でコマンドを簡単に転送できるようにするためです。同じことが、正常に完了したイベントへの応答としてイベントに適用されます。 典型的なDDDアプリケーションでは、ビジネスロジックはエンティティ、値オブジェクト、集約ルート内に存在し、データだけでなく動作も豊富です。ただし、コマンドはドメインオブジェクトではないため、データのドメイン表現に限定されるべきではありません。これは、コマンドに過度の負担をかけるためです。 本当の質問は、ロジックはどこにあるのでしょうか？ 値の組み合わせについていくつかのルールを設定する非常に複雑な集合体を構築しようとすると、私はこの闘争に最も頻繁に直面することがわかりました。また、ドメインオブジェクトをモデル化するときは、フェイルファーストパラダイムに従い、オブジェクトがいつメソッドに到達するかを知ることが有効な状態にあることを好みます。 集約Carが2つのコンポーネントを使用するとします。 Transmission、 Engine。 両方TransmissionとEngine値オブジェクトは、スーパータイプとして表され、サブタイプ、記載しているAutomaticとManualトランスミッション、またはPetrolとElectricそれぞれエンジン。 このドメインでは、それ自体で生活TransmissionするAutomaticかManual、成功するか、それとも、またはいずれかのタイプEngineが完全に作成されます。しかし、Car集約は該当する場合にのみ、いくつかの新しいルールを紹介Transmissionし、Engineオブジェクトが同じコンテキストで使用されています。すなわち： 車がElectricエンジンを使用する場合、許可されるトランスミッションタイプはのみですAutomatic。 車がPetrolエンジンを使用するとき、それはどちらのタイプも持つかもしれませんTransmission。 コマンドを作成するレベルでこのコンポーネントの組み合わせの違反をキャッチできましたが、前に述べたように、コマンドにはドメインレイヤーに限定されるべきビジネスロジックが含まれるため、実行すべきではないことを理解しているからです。 オプションの1つは、このビジネスロジック検証をコマンドバリデータ自体に移動することですが、これも正しくないようです。コマンドを分解し、ゲッターを使用して取得したプロパティを確認し、バリデーター内でそれらを比較して結果を検査しているように感じます。それは私にとってデメテルの法則違反のような叫びです。 上記の検証オプションは実行可能とは思えないため、破棄することは、コマンドを使用してそれから集計を構築する必要があるようです。しかし、このロジックはどこにあるべきでしょうか？具体的なコマンドを処理するコマンドハンドラー内にあるべきですか？それとも、おそらくコマンドバリデーター内にあるべきでしょう（このアプローチも好きではありません）。 現在、コマンドを使用しており、責任あるコマンドハンドラー内でコマンドから集計を作成しています。しかし、これを行うと、CreateCarコマンドが存在する場合、コマンドバリデータがまったく含まれないため、コマンドバリデータがあれば、別のケースで有効であることがわかっているコンポーネントが含まれますが、集計は異なると言う場合があります。 CreateUserコマンドを使用して新しいユーザーを作成する、さまざまな検証プロセスを組み合わせたさまざまなシナリオを想像してみましょう。 コマンドには、Id作成されたユーザーとそのが含まれますEmail。 システムは、ユーザーの電子メールアドレスについて次のルールを示します。 一意である必要があり、 空にしないでください、 最大100文字（db列の最大長）でなければなりません。 この場合、一意の電子メールを持つことはビジネスルールですが、システム内の現在の電子メールのセット全体をメモリにロードし、コマンドで電子メールをチェックする必要があるため、集約でチェックすることはほとんど意味がありません集合体に対して（Eeeek！何か、何か、パフォーマンス。）。そのため、このチェックをコマンドバリデータに移動します。コマンドバリデータはUserRepository、依存関係として受け取り、リポジトリを使用して、コマンドに電子メールが存在するユーザーが既に存在するかどうかをチェックします。 これに関しては、他の2つの電子メールルールをコマンドバリデーターに入れることは突然意味があります。しかし、ルールはUser集約内に実際に存在し、コマンドバリデーターは一意性のみをチェックし、検証が成功した場合は、User集約を作成CreateUserCommandHandlerしてリポジトリに渡し、保存する必要があると感じています。 リポジトリのsaveメソッドは、集約が渡されるとすべての不変条件が満たされることを保証する集約を受け入れる可能性が高いため、このように感じます。ロジック（空でないなど）がコマンド検証自体にのみ存在する場合、別のプログラマーはこの検証を完全にスキップUserRepositoryして、Userオブジェクトでsaveメソッドを直接呼び出すことができ、致命的なデータベースエラーにつながる可能性があります長すぎました。 これらの複雑な検証と変換をどのように個人的に処理しますか？私はほとんど自分のソリューションに満足していますが、選択肢にかなり満足するためには、私のアイデアとアプローチが完全に愚かではないことを断言する必要があると感じています。私は完全に異なるアプローチに完全にオープンです。個人的に何か試してみて、あなたのために非常にうまくいったことがあるなら、私はあなたの解決策を見たいと思います。 1 RESTfulシステムの作成を担当するPHP開発者として働いている私のCQRSの解釈は、コマンドを同期的に処理する必要があるためにコマンドから結果を返すことがあるなど、標準の非同期コマンド処理アプローチとは少し異なります。