問題タブ [anemic-domain-model]

If domain entities aren't anemic, so they embed specific-usage behavior inside themselfes, is there a need/point to use/build specific domain services? How about validation should it go inside an entity?

What way is more flexible for unit testing?

Thanks!

現在、別のチームから引き継いだもののコードレビューを行っており、SRP の適用と貧血またはリッチドメインモデル (Martin Fowler によって定義されている) との関係について 1 つの疑問があります。リッチ ドメイン モデルの概念は、プロパティを設定/取得できるだけでなく、より複雑なビジネス ロジックを実行できるインテリジェントなオブジェクトを持つことです。SRPにどのように適合するのだろうか？

これらの小道具を公開し、そのプロパティでいくつかの簡単な計算を提供できるいくつかのプロパティを持つモデル クラスがあるとします。次の要件は、次のように、このオブジェクト データを自分の管理下にないストレージ オブジェクトに格納できるようにすることです。

ストレージへの格納方法

MyObject にこのような store メソッドがあれば SRP に違反しませんか?

このオブジェクトの視点から、その状態を保存できるのは良い考えです。別の方法として、ここにある種のサービスを導入して、次のようにすることもできます。

この問題について読むことができるリンクを教えてもらえますか? SO here で1つのスレッドを見つけましたが、私の質問に完全には答えていません。

DDD ではどのように解決されますか? DDD のモデルは定義上リッチであり、責任が多すぎると見なすことができます。

一連のアイテムが定義されているとします。これらのアイテムは、異なるセットにグループ化する必要があります。例：アイテムは次のようになります

セットには、このセットに属するアイテム、セットの名前などの独自の設定があります。すべてのものは、xml 構造などに保存されます。

私の最初のアイデアは、次の要素を書くことです：

• セットのデータを取得して MySet pojo に変換する xml パーサー

• すべてのアイテムを取得し、アイテム pojos のリストに変換する xml パーサー

• ステートレス サービスのようなクラスは、ItemsSetCreator が、MySet に基づくセットの定義と次のようなアイテムのリストを含む最終的な ItemsSet オブジェクトを計算すると言います

  /li>

しかし、別のアプローチは、モデルを少し充実させ、sht を次のように記述することです。

• MySet クラスは、すべてのアイテムを取得し、xml-data に基づいてそれらに内部ロジックを適用し、結果として最終的な ItemsSet を提供することができます

• 等

どっちがいいのかわからない。たとえば、Spring がよりサービス中心のアプローチを推進していることは知っていますが、最近貧血モデルの回避について多くの話題があります。

状況：「永続層」にLinqToSql（無関係と見なされる可能性があります）を使用しており、特定の疑わしいビジネス関連のロジックをどこに配置するかについて、アーキテクチャ上の懸念事項を解決しようとしています。

シナリオ：アプリケーションのユーザーが新しい注文を作成します。その場合、プロダクトキーのコレクションをその注文に関連付ける必要があります。

私の最初の試みは、このジャズをすべてOrderServiceクラスに入れることでした。次に、部分的なメソッドを使用して、DataContextに組み込むことを試みました。

これが意図したとおりに機能しないという事実（プロダクトキーが実際に注文に関連付けられることはありません）を無視すると、これはロジックをビジネスドメインから取り除き、「永続化レイヤー」にプッシュしていると感じます。OrderServiceクラスに入れることも考えましたが、ドメインエンティティからロジックを取り除いて、トランザクションスクリプトを作成しただけだと感じました。Order Factoryを導入すると、問題が回避されます。データとロジックが再び分離されます。

だから私の質問はこれです：貧血のドメインモデルを避け、うまくいけば栄光のデータ構造である以外に何かをするために、このロジックを私のドメインモデルに統合する適切な方法はありますか？

私がこれまでに思いついた最善の解決策は、ロジックをOrderクラスに配置し、検証フックで実行されたことを確認することです。

コードの消費は次のようになります。

==2012年3月29日更新==

LinqToSQL（およびWebフォーム）を使用するときにコマンド/クエリパターンを採用し、LinqToSqlDataContextによって作成されたエンティティをデータストアへのマッピング以外のものとして使用しなくなりました。私のすべてのルールとコマンドオブジェクトに入らないものは、ある意味でアプリケーションの真のコアになります。

ADM と RDM の違いを理解しようとしています。

私の見方では、adM と RDM の議論はすべて、ワークフロー (オブジェクトのコラボレーション) を実際に決定する場所に帰着します。RDM は、データ リポジトリ オブジェクトと検証オブジェクトをビジネス オブジェクト (モデル) のコンストラクターに挿入します。ビジネス オブジェクト メソッドは、これらのオブジェクトを連携させるワークフローを定義します。

ADM は、これらすべての共同オブジェクト (モデル、リポジトリ、検証オブジェクトを viewModel/controller などに渡します) を渡します。viewmodel/controller のメソッドは、オブジェクト間のワークフローの共同作業を定義します。

これは正しいですか、それとももっと基本的なものが欠けていますか?

Java EE環境のエンティティBeanは貧血と見なされることを通知するいくつかの記事を読みました（動作を実装せずにゲッターとセッターのみを含むことを意味します）。

動作をエンティティBeanに入れるのを妨げるものは何ですか？セッションBean（ステートレスまたはステートフル）がすべてのビジネスロジックをそれらに委任できるようにするため（ロジックがエンティティによって所有されることを意味するため）。

エンティティBeanが必ずしも貧血である理由がわかりません。

ちょうど今、この質問を入力したところ、興味深いスレッドが表示されました。私はそれが私の質問に答えるとは思わない。

私は貧血モデルを持つことが望ましい.NET MVC3で多くの作業をしてきました。ビュー モデルと編集モデルは、コントローラーからビューに渡すだけのダム データ コンテナーとして最適です。あらゆる種類のアプリケーション フローはコントローラーから来る必要があり、ビューは UI の問題を処理します。MVC では、モデルに動作は必要ありません。

ただし、コントローラーにもビジネスロジックは必要ありません。大規模なアプリケーションの場合は、ドメイン コードをモデル、ビュー、およびコントローラー (および一般的な HTTP) から分離して独立させるのが最善です。そのため、何よりもまずドメイン モデル (DDD に従って集合体に構成されるエンティティと値オブジェクトを含む) を提供する別のプロジェクトがあります。

私は貧弱なモデルから離れてドメインコードのより豊かなモデルに移行しようと何度か試みましたが、あきらめることを考えています. データと動作の両方を含むエンティティ クラスが SRP に違反しているように思えます。

たとえば、電子メールを作成する、Web での非常に一般的なシナリオを考えてみましょう。何らかのイベントが発生した場合、EmailTemplate、EmailAddress、およびカスタム値を指定して EmailMessage オブジェクトを作成するのはドメインの役割です。テンプレートはプロパティを持つエンティティとして存在し、カスタム値はユーザーによる入力として提供されます。また、引数のために、EmailMessage の FROM アドレスを外部サービス (IConfigurationManager.DefaultFromMailAddress) から提供できるとしましょう。これらの要件を考えると、豊富なドメイン モデルにより、EmailTemplate に EmailMessage を構成する責任を与えることができるように思われます。

これは、リッチ ドメイン モデルに対する私の試みの 1 つです。ただし、このメソッドを追加した後は、エンティティ データ プロパティを含めてメッセージを作成するのは EmailTemplate の役割でした。それは約 15 行の長さで、EmailTemplate の本当の意味からクラスの注意をそらすように見えました。つまり、EmailTemplate は単にデータ (件名の形式、本文の形式、添付ファイル、オプションの差出人/返信先アドレス) を格納することです。 ）。

私は最終的に、このメソッドを、前の引数が与えられた場合に EmailMessage を作成することだけを担当する専用クラスにリファクタリングしました。実際、貧血ドメインを好むようになってきました。責任を分離し、クラスと単体テストをより短く、より簡潔に、より集中的にするのに役立つからです。エンティティやその他のデータ オブジェクトを「動作のない」ものにすることは、責任を分離するのに適しているようです。それとも私はここで軌道に乗っていませんか？

たとえば、Jobeetチュートリアルのようにフロントページを考えてみましょう。

クラスCategoriesRepositoryはEntityRepositoryを拡張します{

}

したがって、コントローラー内では、両方のリポジトリーを使用するためにサービスレイヤーを使用する必要はありません。

誰かアドバイスをいただけますか？

Martin Fowlerから理解できることから、貧血とは、ドメインの動作がサービスレイヤーに移動する一方で、ビジネスロジックをドメインオブジェクトから分離することを意味します。私は何かが恋しいですか？

動作がない場合、どのようにオブジェクトドメインを呼び出すことができますか？貧血ドメインモデルの非常に簡単なコードを教えてください。

主に学習目的で、住宅ローン計算ツールの設計を最適化できる領域を検討しています。貧血ドメインモデルについて読んだ後、リッチモデルの作成に興味を持ち、現在の実装に貧血がある可能性があることに気づきました。擬似コードの現在の実装は次のとおりです。

現在、Mortgageオブジェクトは、主にオブジェクト間のデータ転送などに使用されます。

これが私が検討しているいくつかの改訂オプションです：

1. MortgageCalculatorからMortgageオブジェクトを削除し、計算機のメソッドが引数を取る間、Mortgageを純粋にDTOとして使用します（例：calculateMonthlyPayment（loanAmount、interestRate）。これは、MortgageCalculatorをMortgageオブジェクトから分離するのに役立ちますが、Mortgageはアネミックモデルとして使用されます。 。
2. 両方のクラスを1つの「豊富な」MortgageCalculatorモデルにマージします。このモデルには、ビジネスロジック（例：calculateMonthlyPayment）と住宅ローンのプロパティ（例：loanAmount）の両方が含まれています。ここでの私の懸念は、電卓オブジェクトがそのオペランドをインスタンス変数として保持する必要があるかどうかわからないことですが、それらはデータの転送、保存を容易にし、おそらく貧血を解決しますか？

私は理想的なアプローチは何であるか、または私が要点を逃しているかどうか疑問に思っていますか？