このトピックは、ドメイン駆動設計、貧血、血液の損失や輻輳モデルとドメイン駆動設計の使用に関連して議論したいです。私は多くのアプリケーションで、現在の問題を議論したいことをする前に、私は、私がこのような記事を参照しているため、このトピックの原因があると思う「InfoQでは上記で最大の欠陥春のWebアプリケーション（、」このタイトルは非常に魅力的、と言っています「・ω・`）。今ではほとんど春のJavaのWebアプリケーションフレームワークは、非常に心配されているアプリケーションの主な内容や視点、このようなもの、および単一責任の原則との懸念原理の分離が、これの上など、あまり良いアンチパターンと設計原則のいくつかの誕生でした：
- オブジェクト・モデルのフィールドのみ（抗パターンモデルを用いて、貧血ドメインモデル）ストア・アプリケーション・データに使用されます。
- サービス層、オブジェクト管理データ領域でのビジネスロジック。
- サービス層では、各サービスアプリケーションエンティティ・クラスに対応します。
設計原理のこのタイプは広く、私はこのプロジェクトは、彼らが好きなものについては、基本的な3層以上が共通のアーキテクチャは、Javaのウェブこの設計アーキテクチャの設計原理を使用することで今の私、使用されていますか？
- ウェブ層（一般的にプレゼンテーション層、右、プレゼンテーション層として知られている）：ユーザーの入力、サービスレイヤに送信されたデータを受信します。
- サービス層（サービス層は、ビジネスロジック層と呼ばれることができます）：トランザクション境界、ビジネスロジックの処理、著作権管理と承認、およびストレージ層と通信し、
- メモリ層（データアクセス層）：データベース、データの永続性と連通します。
しかし、何も見つかりませんでしたか？サービス層における問題の嘘は、彼が責任、トランザクション管理、ビジネスロジックの多くを負って、その単一責任の原則や懸念の分離の原則に違反し、依存性と循環依存関係の多くを生成した権限チェックのように。ビジネスの複雑さが増加すると、コードがサービス層に含まれる場合、試験のコスト上昇の直接的な結果で非常に大規模で複雑になります。
私は、現在のプロジェクトで、ここでの例を持っているために、コードの4,000以上の行を含む、コアクラスの保険事業単位を、処理する責任起こり、それが参照（注射）に関連付けられたデータベーステーブルダースDAOへの鍵であります。ビジネスの様々な政策、再保険、クレームなどを扱うことができる方法の種類の数十で、それはまた、休止状態の深さに依存し、ORMのアプローチのデータを使用するだけでなく、さらに直接使用HQLは、データを取得します。他の多くのサービスクラス彼と循環参照があるので、誰も彼が最終的に何ができるかを知らないので、プロジェクト後でこの怪物変化に誰もあえては、再建は不可能です。
サービス層に関するいくつかの悪い事はそれを改善するためにどのようにあるべき、と述べましたか？
- まず、我々はドメインモデルにサービス層からビジネスロジックを移動する必要があり、この利点は、サービスのみ（など、トランザクションを開始し、終了し、そのようなデータの検証として、認証チェック）アプリケーションロジック層を担当することができるということです、自分のドメインモデルの原因となり得ます関連するビジネスロジック。またはポリシーシステムの前の距離で、関連するビジネスモデルをモデル化し、完全に政策に対して、再保険のアーキテクチャ設計、請求の範囲及び他の分野のモデルは、それぞれ、異なる領域にありそうなリピートビジネスの一部を配置することができますペーストの可能性 - コードは、それによってコピーを低減する、一箇所に集められます。
- 第二に、サービスクラスは、それが一つの役割のためにのみ責任があるように、小さくなります。記事は一例であり、そのようなCRUDユーザーアカウントなど、他の操作は、ユーザーアカウントに関連する他の業務を担当するサービス、CRUD操作がアカウントに1つ、および他の2つの異なるクラスにそれを置くことができます。
理解し、再利用するために、他の人のコストを削減しながらこれは、緩い、テストすることができ、サービスクラスが小さくなることができます。
次の質問は、これらの設計原則を実践する方法を、実際のプロジェクトでは、ありますか？
「があり、ドメイン駆動設計・開発の実践は、」Aは一見の価値が、彼は階層を尊敬し、上記と同様、さらにいくつかのルールの詳細を作りました：
- サービス層は、アプリケーション・ロジック、ユーザーセッションの管理が含まれている必要がありますが、ドメインロジック、ビジネスロジックとデータアクセスロジックを含めることはできません。
- FIELD層（オブジェ）は、ビジネス・ロジックは、サービスに関連するセッション状態を処理することができます含まれている必要があります。コアビジネスアプリケーションが良い移植性を持つべきであるとしてではなく、特定のフレームワーク（例えば、Strutsのは、Hibernate、EJBなど）への依存を生成することはできません。
ここでは、最終的には議論の話題に - 貧血、血液の損失と輻輳モデル。失血性貧血の輻輳モデルは何ですか？簡単に
- モデルの出血：モデルは、サービス層へのデータの定義およびgetter / setterメソッドは、アプリケーション・ロジックとビジネス・ロジックが含まれています。このクラスは、.NET POCOで呼ばれる、JavaでPOJOと呼ばれています。
- 貧血モデル：貧血モデルは、いくつかのビジネスロジックが含まれていますが、ビジネスロジックに依存する持続性が含まれていません。ビジネスロジック層のこの部分は、サービス層への持続に依存します。図から分かるように、物体視野貧血モデルは、永続層に依存しません。
- うっ血性モデル：充血モデルは、すべてのビジネスロジックを含み、持続性を含め、ビジネス・ロジック層に依存します。そのため、ドメイン層の混雑モデルの使用は永続層に依存して、単純に示すようUIレイヤ - >サービス・レイヤー - >レイヤーのフィールド< - >永続化層。
- 拡張モデルブラッド：ブラッド展開モデルは、他のアプリケーションロジック（例えば、承認、トランザクションなど）にあるモデルに配置されているビジネス・ロジック関連技術を望んでいません。私は血が腫れを感じるが、サービス層が消失し、乾物のドメイン層、サービス層は、最終的にはまだ何も変わっていないので、このモデルは、血液の損失の別のモデルです。
、血液損失モデルと拡張モデルの血は望ましいものではない、問題は今、貧血、より優れているうっ血モデルモデルは見ることができます。昔、人々は終わり、まだ何もありませんで、この問題論争アドレスを長期化されました。ここではいくつかの記事可能な後味は以下のとおりです。
永続層手段に依存するが、テキストを議論する枠組み外（より困難ではないテストするためのテストユニットを拡大するための議論の主な焦点は、私は上記の太字の2つの文における両側、ドメインモデルは、永続層するか否かに依存していますここでは、より困難な層は芸術分離すること、およびより困難なアプリケーションからの皮に、当然のことながら、必要ない方が良いが、単一の役割の性質を反映するように、異なる層でのビジネスロジックの利点をミックスします）休止状態に特異的に言及。長い永続層の要約として、あなたはすべての後に、テストの難易度を減らすことができますよう、混雑モデルを適用することを提案者（充血モデル）が離れてより多くの持っている永続化層に依存するから多くの開発者の利便性をもたらします充血モデルはまだを活用して価値があります。最後に、誰がどのように貧血モデルと渋滞のモデル、より決定するために、特定のビジネスシナリオに頼る選ぶ説得することはできない、と我々は1つが優れているよりもあると言うことはできません。デザインパターンは、このようなことは、どのような決定的常にではないではありません。
もっとうまく設計されたシステムアーキテクチャ、および優れたコンピュータの世界のように、永続層に依存IOCとDIフレームワーク、唯一の欠点の多くで、代替の様々な方法によりバイパスすることができますがあり混雑モデルがあるので、私は個人的に、輻輳モデルを使用する傾向があります技術の進歩とともに、いくつかの欠点が徐々に解決されます。インターフェイスのための抽象化の最初の永続化層、および永続化層、サービス層は、ドメインモデルに注入されて、その後、このモデルは唯一のインタフェースの永続層の面積に依存します：私の考えはこれです。このインターフェイスは、既存の技術のフレームワークを使用して抽象化することができます。例えば、休止状態IのJavaバージョンは、例えば、.NET Entity Frameworkのに関しては、あまり知りません。
さて、このようなDbContext、我々はすべて知っている、DbContextとDbSetは非常に悪いモック二つのクラスが存在している（私はあまりにも面倒だった、専門家は無視してください）、二つのテーブル、他のアニメユーザーを呼び出すと呼ばれる1があります
どのように使用して、両方を容易にするインタフェースを設計すると、あなたは簡単にそれをテストすることができますか？インタフェースの直接抽出？DbSet容易ではない模擬問題は、それを解決していません。
幸いなことに、我々はLINQとのIQueryable <T>を持って、単に外観を変換、インターフェースはこのようになります。
IQueryable LINQオブジェクトがある操作を、サポートすることです実装のIQueryable <T>オブジェクトを返します。注クエリ<T>（）メソッドは、我々はまだ、式DbContextの検索に本当のことができやる、このDbContextの必要性のみ単文します：
db.Query <アニメ>（）内からの問い合わせへのdb.Anime.AsQueryable（）内からから、すべてが落ち着いています。あなたはユニットテスト時間の誤ったデータソースを返すようにしたい場合は、直接FakeDb.Query <T>（）メソッドは、誤ったデータがそれにリスト<T> .AsQueryableを（）が返されます。ドメイン層とデカップリングの永続化層のこの実現には、すべての後に、ジェネリックのIQueryableものです。