DDDでは、検証アプリケーションロジックですか、それともドメインロジックですか？
DDDを使用してフォームをモデリングしているとします。フォームには、特定の種類のビジネスルールが関連付けられている場合があります。学生でない場合は収入を指定する必要があり、結婚していることを示す場合は子供をリストする必要があります。国を指定した場合は、有効な国が必要です。
この種の検証はドメインまたはアプリケーション層に存在しますか？私が検討していたいくつかの他の問題：
Laravelなどの特定のフレームワークは、リクエストがコントローラーに到達する前に入力を検証できる検証ルールを提供します。そのレベルで検証が行われた場合、DDDは無効になりますか？
国が有効かどうかを判断するような場合、通常は世界のすべての国のデータベーステーブルをクエリします。ただし、DDDでは、これは（私の理解から）ドメイン層で行われる可能性があります。ドメインレイヤーはDBへのアクセスを許可されていますか、それとも有効な国を特定するために非SQL検索を使用する必要がありますか？
アプリケーションとドメイン層の両方で入力を検証する必要がありますか？
この種の検証はドメインまたはアプリケーション層に存在しますか？
応用。必要な魔法の検索用語は 破損防止レイヤー です。
通常、アプリケーションが受信するメッセージは、DTOの一種です。不正防止レイヤーは通常、ドメインが認識する値タイプを作成します。ドメインモデルにディスパッチされた実際のコマンドは、検証された値の型で表現されます。
例：DepositMoneyコマンドには、金額と通貨タイプが含まれる可能性があります。 DTO表現はおそらく金額を整数として表し、通貨コードは文字列として表します。不正防止レイヤーは、DTOを預金値タイプに変換します。これには、検証済みの金額（負でない必要があります）と検証済みのCurrencyCode（ドメインでサポートされているコードの1つである必要があります）が含まれます。
ドメインモデルが理解できるタイプにコマンドを正常に解析した後、コマンドはドメインで実行されますが、ビジネスインバリアントに違反するという理由でコマンドを拒否する可能性があります（アカウントがまだ存在せず、アカウントがブロックされている、この特定のアカウントはその通貨の使用を許可されていませんか？など）。
言い換えれば、腐敗防止層が入力を検証した後、ビジネス検証はドメインモデルで行われます。
検証ルールの実装は、通常、値タイプのコンストラクター内、または値タイプの構築に使用されるファクトリーメソッド内にあります。基本的に、オブジェクトが有効であることが保証されるようにオブジェクトの構築を制限し、ロジックを1か所に分離して、プロセスの境界でそれを呼び出します。
問題ドメインモデルには、ドメインビジネスルールが含まれています。ビジネスルールは、モデルの要素に対する制約です。ドアが開いたままエレベーターが動かないこと、生鮮品が非冷蔵コンテナに積み込まれないこと、キャンセルされた注文が発送されないことを意味します。
これは、ドメインが（画面、フォームなどを介して）人間と対話するときに、検証や支援が必要ないという意味ではありません。オプションであることを理解してください。
ビジネスルールには2つのタイプがあることを考慮してください。オブジェクトの属性を制約するプロパティルールと、オブジェクト間のコラボレーションの追加と削除を制約するコラボレーションルールです。
ビジネスルールは、プログラミング言語に関連するロジックルールとは異なり、値が指定されていてnullでないことを確認します。
注：フォームを「モデル化」するというDDDの概念はありません。
特定の状態はモデルエンティティを無効にしますか？はいの場合、モデルはエンティティがその状態になるのを防ぐ必要があります。つまり、モデルはそれ自体を検証する方法を知っている必要があります。
しかし、わずかな問題があります。モデルの検証は、多くの場合、手遅れです。多くの場合、早期に検証を行いたいので、ユーザーはあまり長く待つ必要はありません。そのため、検証がアプリケーションロジックによく使用されます。
検証のコンテキストについては、エンティティが追加のデータを照会できるという問題はありません。しかし、それらのデータがどこから来たかは気にする必要はありません。それがSQL、ファイル、またはハードコードされたものであるかは問題ではありません。そのため、リポジトリが存在します。ドメインは、必要なクエリの種類を定義し、他の誰かが実装を処理できるようにします。