design-patterns - 貧血ドメイン モデルとドメイン モデルの比較

Question

SO でこのアンチパターンとそれに関する多くの懸念について読んだ後、再び混乱しています。

ドメイン モデルがあり、データ転送オブジェクトに永続化する必要があるデータをキャプチャする場合、ドメイン モデルはデータのラッパーになりますか? その場合、貧血ドメイン モデルを使用します。しかし、そのラッパーに十分なドメイン ロジックを追加すると、どの時点で実際のドメイン モデルになるのでしょうか?

ドメイン モデルで永続化する必要があるものをキャプチャすることは、優れたプラクティスに違反し、貧血ドメイン モデルのアンチパターンを作成するという印象を受けます。しかし、リレーショナル DB を使用する場合、オブジェクトの状態を構成する部分を特定して保存することを避ける方法はありません。

私は概念についてかなり混乱しているので、私が書いていることが意味をなすかどうかはわかりません. 気軽に質問してください。

Answer 1

ビジネス ドメインを構成する動作のすべて(またはほとんど) が含まれている場合、それは「実際の」ドメイン モデルになります ( UI やその他の直交する問題ではなく、ビジネス ロジックを強調していることに注意してください)。

ユビキタス言語を使用していて、ドメインの専門家から絶え間なくフィードバックを受けている場合は、正しい方向に進んでいることがわかります (専門家はドメイン モデルを見てうなずくはずです)。これらのことを行っていない場合、DDD を行っていません ( Eric Evans がそれについて語っています)。

DTO の要点: それらを無視しないでください。実装の観点からは、レイヤー/層の間でデータを転送するためにそれらが必要になります。DTO と真のドメイン オブジェクトをどのように組み合わせるかは、使用しているテクノロジによって異なります。

以前の回答でほのめかされたように、データと永続性に重点を置いているために、真のドメイン モデリングから気をそらしている可能性があります...

Answer 2

2 つの興味深い項目が頭に浮かびます。

• データ転送オブジェクト (DTO) は、ドメイン オブジェクトとは異なります。これらは、アーキテクチャ内のさまざまな場所でさまざまな目的を果たします。混同しないでください。ドメイン オブジェクトは、凝集度の高い豊富な APIを提供します。DTO は、アプリケーションの外部インターフェイスで使用される受動的なデータ構造です。UI ViewModel によく似ていますが、ユーザーではなく自動化されたシステムを対象としています。
• Persistence Ignoranceを使用できる ORM を選択してから努力してください。これは、制限のない方法でドメイン モデルを定義し、ORM でオブジェクトをリレーショナル データベースにマップするだけでよいことを意味します。

Answer 3

しかし、そのラッパーに十分なドメインロジックを追加すると、どの時点で実際のドメインモデルになりますか？

偶然に何かを追加することによってドメインモデルに到達することは可能ですが、ドメイン駆動設計ではありません。（これはあまり役に立たないことを私は知っています。私は非常にデータ中心であると考える傾向があり、場合によっては、この観点から自分自身を引っ張るのに本当に努力が必要です。）