DDDについての熱心な研究の背景に対して、2003年11月25日にMartin Fowlerが書いたAnemic Domain Modelの記事を読みました。 時々、資料をよりよく理解するために、ロシア語に翻訳します。 だから私は翻訳を共有することにしました。
著者の翻訳といくつかの場所では非常にセマンティックです。
オリジナルへのリンク。
記事にはすでに出版された本からの引用があり、専門家によってロシア語に翻訳されました。翻訳の理解を深めるために、ネタバレの下で本から引用を引用しました。
ペールドメインモデル
これは私たちを長い間取り囲んできたアンチパターンの1つであり、今ではさらに積極的に現れています。 私はこれについてエリック・エヴァンスと話しましたが、私たちは両方とも彼がより人気を博していることに気付きました。 そして、適切なドメインモデルのサポーターとして、これは良くないと思います。
ペールドメインモデルの最初の症状は、一見しただけでは正常に見えることです。 オブジェクトは、サブジェクト領域から名詞として名前が付けられ、相互接続され、通常のドメインオブジェクトのような構造を持っています。 コンテンツを見ると理解が得られますが、それはゲッターとセッターのセット以上のものではありません。 多くの場合、これらのドメインオブジェクトには、ドメインロジックを配置しないというアーキテクチャルールが付属しています。 代わりに、すべてのドメインロジックを含む一連のサービス（サービスオブジェクト）があります。 これらのサービスは、アーキテクチャ的にドメインモデルの上にあり、データソースとして使用します。
このアンチパターンの全体的な恐怖は、オブジェクト指向設計の基本的な考え方に反することです。オブジェクト指向設計は、データとプロセスを組み合わせることで構成されます（動作）。 淡いモデルは手続き型のデザインのようなもので、私やエリックのようなファンは、Smalltalkでの最初の仕事以来苦労してきました。
最近、オブジェクト指向の純粋主義は優れていますが、モデルのこの「pal色」に対してより説得力のある議論が必要だと思います。 Pale Domain Modelの問題は、その利点を導入することなくDomain Modelのすべての負担を担っているということです。 そして、通常はORMレイヤー全体となるデータベースマッピングの不合理さでこれにお金を払っています。 これは、複雑なロジックを整理するために強力なオブジェクト指向技術が使用されている場合にのみ意味があります。 ただし、システムのすべての動作をサービスに移すと、すべてがTransaction Scriptsで終了することを理解する必要があり、もちろんドメインモデルがもたらすすべての利点が失われます。 しかし、EAAのPで述べたように、ドメインモデルが常に最良の選択とは限りません。
また、ドメインオブジェクトでの動作の配置は、ドメインロジックを永続性およびプレゼンテーションレイヤーから分離するためにレイヤーを使用する一貫したアプローチと矛盾すべきではないことも注目に値します。 ドメインオブジェクトにあるべきロジックは、ドメインロジックです。たとえば、検証、計算、または「ビジネスルール」と呼ばれるものです。
（もちろん、パラメータを介してドメインオブジェクトにデータソースまたはプレゼンテーションロジックの一部を渡す場合もありますが、これは「pallor」という私の考えに直交しています。）
誤解の原因の1つは、多くのオブジェクト指向の専門家が、サービスレイヤーを形成するために、ドメインモデル上に手続き型サービスのレイヤーを配置することを推奨していることです。 しかし、これはドメインモデルに動作を配置しないという議論ではありません。実際、サービスレイヤーは、動作を含むドメインモデルと組み合わせて使用することを推奨します。
Eric Evansの優れた本であるDomain Driven Designは、これらのレイヤーについて次のように述べています。
アプリケーション層[彼はサービス層と呼ぶ]：アプリケーションが解決することになっているタスクを定義し、その実行を（リッチな）ドメインモデルに向けます。 この層のタスクは、ビジネス（ビジネスロジックではない）にとって重要であるか、単に他のシステムのアプリケーションレベルとの対話です。 この層は薄いままにしてください。 ビジネスロジックや知識は含まれていません。タスクを調整するだけで、下位レベルのドメインオブジェクトのセットに作業を委任します。 ビジネスロジックの状況を反映する状態は保持しませんが、ユーザーやアプリケーション全体に通知するタスクのステータスを知ることができます。
本から
タスクが解決すべきタスクを定義し、サブジェクト領域の本質を表現するオブジェクト間でそれらを分配します。 このレベルで実行されるタスクは、スペシャリストユーザーにとって意味のあるものであるか、他のシステムの運用レベルとのインタラクティブな対話に必要です。 このレベルでは、サイズを「膨張」させる必要はありません。 知識もビジネスルール（ビジネスルール）も含まれていませんが、タスクの調整とサブジェクトエリアのオブジェクトセット間の作業の分配のみが次の下位レベルで実行されます。 アプリケーションモデルのオブジェクトの状態は反映されませんが、ユーザーに通知するタスクの完了の程度をユーザーに通知する状態が含まれる場合があります。
ドメインレイヤー（またはモデルレイヤー）：ビジネスプロセスの意味を表す責任があり、ビジネスの状況とビジネスルール（ビジネスロジック）に関する情報を伝達します。 ここでは、アプリケーション（ビジネスパート）の状況を反映する状態が監視および使用され、データストレージ（永続性）の技術的な詳細もインフラストラクチャに委任および委任されます。
この層はアプリケーションの中心です。
本から
彼は、適用対象分野、労働条件、事業規制の概念のプレゼンテーションを担当しています。 ここでは、データ操作の技術的な詳細がインフラストラクチャに委任されている場合でも、アプリケーションモデルの現在の状態が監視および使用されます。 このレベルは、プログラムの主要なアルゴリズム部分です。
ここでのポイントは、サービス層が薄く 、すべてのロジックがドメイン層にあるということです。 彼（Eric）は、 サービステンプレートでこれを繰り返します。
適切なオブジェクトにビヘイビアーを配置するときに、あきらめすぎて、手続き型プログラミングに徐々に滑り込むのはよくある間違いです。
本から
この時点で、よくある間違いを犯すのは簡単です。操作を適切なオブジェクトに配置しようとする試みを放棄し、手続き型プログラミングになります。
このアンチパターンがそれほど一般的である理由はわかりません。 これは、特にデータの世界から来た場合には、 正しいドメインモデルで作業しなかった人が非常に多いという事実から推測します。 J2EEのEntity Beanなど、一部のテクノロジーはこのアンチパターンを奨励しています。これが、私がPOJOドメインモデルを好む理由の1つです。
一般に、サービスのロジックが多くなればなるほど、ドメインモデルのメリットを享受できなくなったように見えます。 そして、あなたのすべてのロジックがサービスであるなら、あなたは愚かに自分を奪った。
ご清聴ありがとうございました。
私はそれを必要としないので、私は招待するふりをしません。 しかし、もし誰かがその資料が招待する価値があると思ったら、コメントで知らせてください、私は喜んでいます。