焦点を絞り込むために、ここで質問を単純化しました。
リポジトリからのデータが必要な場合に、エンティティ構築のためにドメイン層で検証を実行するための推奨されるアプローチは何ですか?
たとえば、エンティティが作成される前に合格する必要がある次の検証規則を考えてみましょう。
ルール 1: 携帯電話を要求する従業員は、ABC 社で 6 か月以上勤務している必要があります。
UI から発生し、後でアプリケーション層の注文サービスから渡されたドメイン層のエンティティが利用できる情報には、上記のサンプル ルールを適用するのに十分な情報がありません。従業員が 6 か月以上働いているかどうかを計算するために、従業員の雇用日を返すには、リポジトリからクエリが必要です。
質問
問題は、ルール 1 を検証するために必要な従業員の雇用日を取得するために、この時点でどのレイヤーまたはサービスがリポジトリに接続する必要があるかということです。ルール 1 がパスし、エンティティの他のデータ値もパスしない限り、ドメイン エンティティは有効とは見なされません。
前もって感謝します。
OrderValidationData を取得するためのリポジトリへの呼び出しは、アプリケーション サービスにあるべきか、ドメイン層にあるべきか。
ドメイン検証はdomainであるため、ドメイン内のサービスの一部である必要があります。
ドメインによって処理されているデータがドメイン自体で検証されていないドメインと対話するアプリケーション サービス以上のものを想像する必要があります。一部のアプリケーション サービスがいわゆる検証を実行しない場合、ドメインが破損する可能性があるため、これは非常に危険です。
それがドメイン層にある場合、OrderValidationData の呼び出しを行うために必要なリポジトリのインスタンスを注入する必要があると思いますか? また、リポジトリ操作をエンティティに追加しない人がいると読んだので、リポジトリ アクションを実行するためにドメイン サービスを作成する必要があります。
リッチ ドメイン モデルvs貧血ドメイン モデル(リッチ vs 貧血ドメイン モデルを参照)
また、リポジトリでドメインを検証するのはどうでしょうか? 既に を実装している場合ProductRepository、最善の策は、ドメイン オブジェクトが追加または更新されるときにドメイン オブジェクトを検証することだと思います。つまり、すべての上位レイヤーは強制的にリポジトリのルールに従う必要があり、これはドメイン モデルを壊す可能性をゼロに減らしたことを意味します。
ところで、これらの検証を仕様(仕様パターンを参照) として実装して、ドメイン オブジェクトがリポジトリによって永続化される前に、何らかの操作の初期段階でドメインを検証できるようにします。同じ操作内で同じドメイン オブジェクトを検証する必要がある場合があり、仕様は n 層アーキテクチャで検証ルールを再利用するのに適しています。