DDDでは、検証アプリケーションロジックですか、それともドメインロジックですか?


26

DDDを使用してフォームをモデリングするとします。フォームには特定の種類のビジネスルールが関連付けられている場合があります。おそらく、学生でない場合は収入を指定する必要があり、結婚していることを示す場合は子供をリストする必要があります。国を指定した場合は、有効な国が必要です。

この種の検証は、ドメインまたはアプリケーション層に存在しますか?私が検討していたいくつかの他の問題:

  • Laravelなどの特定のフレームワークは、要求がコントローラーに到達する前に入力を検証できる検証ルールを提供します。そのレベルで検証が行われると、DDDが破損しますか?

  • 国が有効かどうかを判断する場合など、通常は世界のすべての国のデータベーステーブルを照会するだけです。ただし、DDDでは、これは(私の理解から)ドメイン層で行われる可能性があります。ドメインレイヤーはDBへのアクセスを許可されていますか、または非SQL検索を使用して有効な国を決定する必要がありますか?

  • アプリケーションとドメイン層の両方で入力を検証する必要がありますか?


6
あなたの質問は、すべてを置く正しい場所が常に1つあると仮定しています。ありません。
ロバートハーベイ

1
@RobertHarveyが言うこと。「アプリケーション」による検証に関係なく、検証は常にモデル上で行う必要があります(モデルはアプリケーションの一部ではありませんか?)。「アプリケーション」内の検証は、モデルの検証の繰り返しである必要があります-UIの応答性を高めるため、または「アプリケーション」ロジックのみに関連する必要があります(「このフォームでは入力のみ可能」のように) ..」ですが、エンティティの検証を想定していました)。ドメインの検証のための「アプリケーション」層を決して信用しないでください、それはあなたのクライアントが...情報を送信することはできません
マージャンVenema氏

回答:


29

この種の検証は、ドメインまたはアプリケーション層に存在しますか?

応用。必要な魔法の検索用語は、腐敗防止レイヤーです

通常、アプリケーションが受信するメッセージは、DTOのフレーバーです。通常、腐敗防止レイヤーは、ドメインが認識する値タイプを作成します。ドメインモデルにディスパッチされる実際のコマンドは、検証された値の種類で表現されます。

例:DepositMoneyコマンドには、通常、金額と通貨タイプが含まれます。DTO表現は、おそらく金額を整数で表し、通貨コードを文字列で表します。腐敗防止レイヤーは、DTOをDeposit値タイプに変換します。これには、検証済みのAmount(負でない必要があります)および検証済みのCurrencyCode(ドメインでサポートされているコードのいずれか)が含まれます。

コマンドをドメインモデルが理解できるタイプに正常に解析すると、コマンドはドメインで実行されます。これは、ビジネス不変条件に違反するという理由でコマンドを拒否する可能性があります(アカウントがまだ存在しない、アカウントがブロックされている、この特定のアカウントはその通貨を使用できませんか?など)。

言い換えると、破損防止レイヤーが入力を検証した後、ドメインモデルでビジネス検証が行われます。

検証ルールの実装は、通常、値型のコンストラクター、または値型の構築に使用されるファクトリメソッド内に存在します。基本的に、オブジェクトの有効性が保証されるようにオブジェクトの構成を制限し、1か所でロジックを分離し、プロセスの境界でそれを呼び出します。


なぜアプリケーションが答えなのですか?テキストによると、正式な検証はドメインまたはアプリケーションの両方で実行でき、ビジネス検証はドメインのみで実行できます。
-inf3rno

@ inf3rnoため、具体的ドメインに関連していないフォーム、確認について尋ねられる質問
timetofly

1
この答えは意味がありません。DDDの腐敗防止レイヤーは、(別のシステムの)外部ドメインモデルとDDDベースのアプリケーションのドメインモデルとの間で変換するために記述する追加のコードです。そのような外部システムがない場合、腐敗防止レイヤーはありません。また、ビジネスルールの検証は、アプリケーション層ではなく、ドメインモデル(およびドメイン層)に属します。DTOに関しては、これはDDDアプリに存在する場合と存在しない場合がある技術コンポーネント(アプリケーション層内)です。DTOとエンティティ/ ValueObject間の変換は、腐敗防止レイヤーとは関係ありません。
ロジェリオ

5

問題のドメインモデルには、ドメインのビジネスルールが含まれます。ビジネスルールは、モデルの要素に対する制約です。それらは、ドアが開いた状態でエレベーターが動かないこと、腐りやすい商品が冷蔵されていないコンテナに積み込まれないこと、キャンセルされた注文が出荷されないことを意味します。

これは、ドメインが(画面、フォームなどを介して)人間とやり取りするときに、検証や支援が不要であることを意味するものではありません。それがオプションであることを認識してください。

ビジネスルールには2つのタイプがあることを考慮してください。オブジェクトの属性を制限するプロパティルールと、オブジェクト間のコラボレーションの追加と削除を制限するコラボレーションルールです。

ビジネスルールは、プログラミング言語に関連するロジックルールとは異なり、値が指定されており、nullなどではないことを確認します。

注:DDDにはフォームの「モデリング」という概念はありません。


0

特定の状態はモデルエンティティを無効にしますか?はいの場合、モデルはエンティティがその状態にならないようにする必要があります。つまり、モデルはそれ自体を検証する方法を知っている必要があります。

しかし、わずかな問題があります。モデルの検証はしばしば遅すぎることがあります。多くの場合、検証を早期に行いたいので、ユーザーはあまり長く待つ必要はありません。検証がしばしばアプリケーションロジックに組み込まれる理由です。

検証のコンテキストに関して:エンティティが追加データを照会できるという問題はありません。しかし、それらのデータがどこから来たかは気にする必要はありません。SQL、File、または単にハードコーディングされているかどうかは関係ありません。それがリポジトリが存在する理由です。ドメインは、必要なクエリの種類を定義し、実装を他の誰かに任せることができます。


-2

ドメイン層には、すべての検証ロジックが含まれている必要があります。プレゼンテーション、腐敗防止レイヤー、またはその他の依存レイヤーはそれを反映する必要があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.