Anemic_domain_model
貧血ドメインモデルは、ドメインオブジェクトにビジネスロジック（検証、計算、ビジネスルールなど）がほとんどまたはまったく含まれていないソフトウェアドメインモデルの使用です。
コンテンツ
1 概要2 批判 3 負債
4 例
5 も参照してください
6 参考文献
7 外部リンク
概要
このパターンは、この慣行をアンチパターンと見なしているMartinFowlerによって最初に説明されました。彼は言う：
このアンチパターンの根本的な恐怖は、オブジェクト指向設計の基本的な考え方に反していることです。これは、データを組み合わせて一緒に処理することです。貧血ドメインモデルは単なる手続き型の設計であり、まさに私のようなオブジェクトの大物が… Smalltalkの初期の頃から戦ってきたようなものです。さらに悪いことに、多くの人は貧血のオブジェクトは実際のオブジェクトであると考えているため、オブジェクト指向デザインの本質を完全に見逃しています。
貧血のドメイン設計では、ビジネスロジックは通常、ドメインオブジェクトの状態を変換する個別のクラスに実装されます。Fowlerは、このような外部クラスのトランザクションスクリプトを呼び出します。このパターンは、中に一般的なアプローチであるのJavaおそらく、このような初期のバージョンなどの技術によって奨励、アプリケーションEJBのエンティティBean、にだけでなく、.NETのようなオブジェクトがカテゴリに分類される三層サービスアプリケーションアーキテクチャ以下のアプリケーション「ビジネスエンティティ」の（ただし、ビジネスエンティティには動作を含めることもできます）。
Fowlerは、トランザクションスクリプトパターンを次のように説明しています。
ほとんどのビジネスアプリケーションは、一連のトランザクションと考えることができます。トランザクションは、特定の方法で編成されたものとして一部の情報を表示する場合があり、別のトランザクションはそれに変更を加えます。クライアントシステムとサーバーシステム間の各相互作用には、一定量のロジックが含まれています。場合によっては、これはデータベースに情報を表示するのと同じくらい簡単なこともまた、検証と計算の多くのステップが含まれる場合もトランザクションスクリプトは、このすべてのロジックを主に単一のプロシージャとして編成し、データベースを直接呼び出すか、シンデータベースラッパーを介して呼び出しを行います。各トランザクションには独自のトランザクションスクリプトがありますが、一般的なサブタスクはサブプロシージャに分割できます。
Fowlerは、著書「Patterns of Enterprise Application Architecture」で、トランザクションスクリプトパターンは多くの単純なビジネスアプリケーションで問題なく、複雑なオブジェクト指向データベースマッピングレイヤーを不要にすると述べています。
これが発生する理由
AnemicDomainModelは、動作が移動しない、または移動しない傾向があるサービス指向アーキテクチャーの影響を受けるシステムで発生する可能性が
メッセージング/パイプラインアーキテクチャ
SOAP / RESTなどのAPI
COM +やRemotingのようなアーキテクチャは動作を許可しますが、Webはますます切断されたステートレスアーキテクチャを好むようになっています。
批判
このソフトウェアデザインパターンをアンチパターンと見なすべきかどうかについては、いくつかの批判がたとえば、次のような利点もあると多くの人が考えているからです。
ロジックとデータを明確に分離します。
単純なアプリケーションに適しています。
ステートレスロジックが生成され、スケールアウトが容易になります。
複雑なオブジェクト指向データベースマッピングレイヤーの必要性を回避します。
特定のコンストラクターやプロパティの母集団の順序ではなく、ダムプロパティを期待するマッピングおよびインジェクションフレームワークとの互換性が向上しました。
負債
ロジックは、真にオブジェクト指向の方法で実装することはできません。
カプセル化および情報隠蔽の原則への違反。
ドメインモデルにあるロジックを含めるには、別のビジネスレイヤーが必要です。また、ドメインモデルのオブジェクトは、検証とミューテーションロジックが外部のどこかに配置されているため（ほとんどの場合、複数の場所に配置されているため）、いつでもその正確性を保証できないことを意味します。
オブジェクトモデルの異なるコンシューマー間でドメインロジックを共有する場合は、サービスレイヤーが必要です。
モデルの表現力を低下させます。
例
貧血
クラス Box { public int Height { get ; セット; } public int Width { get ; セット; } }
非貧血
クラス Box { public int Height { get ; } public int Width { get ; } public Box （int height 、 int width ） {
if （height <= 0 ） {
throw new ArgumentOutOfRangeException （nameof （height ））; } if （width <= 0 ） {
throw new ArgumentOutOfRangeException （nameof （width ））; } 高さ = 高さ;
幅 = 幅; } public int Area （） {
return Height * Width ; } }
も参照してください
プレーンオールドJavaオブジェクト
ドメイン駆動設計
GRASP情報エキスパート、貧血ドメインモデルは、情報エキスパートの原則を適用しないことの典型的な結果です。つまり、データを含む同じクラスに責任を割り当てようとすることで、貧血ドメインモデルを回避できます。
参考文献
^ http://www.martinfowler.com/bliki/AnemicDomainModel.html ^ 「アーカイブされたコピー」。
^ https://www.martinfowler.com/eaaCatalog/transactionScript.html ^ http://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/
外部リンク
マーティンファウラーによる貧血ドメインモデル
3層サービスアプリケーション
.NETのアプリケーションアーキテクチャ：アプリケーションとサービスの設計
貧血モデルが優れたデザインと見なされる理由に関する記事
ASP.NETでクリーンなコードを書く
貧血ドメインモデルを回避する方法“