DDD-貧血ドメインモデルはアンチパターンですか？リッチドメインモデルを使用しているのでしょうか。[閉まっている]

貧血ドメインモデルは、明らかにオブジェクト指向の原則などに反するため、EvansとFowlerによって以前から批判されていました。DDDコミュニティは、この発言と明確に一致しています。

しかし、近年、これはアンチパターンではなく、SOLIDの原則に従う例であると主張する意見の相違があります。

私は長年、Spring Frameworkを使用して作業してきました。すべての会社のすべてのプロジェクトには、貧血モデル（JPAエンティティ）で動作するリポジトリを使用して、ビジネスロジックを含むサービスレイヤーが常にあります。さらに、ほとんどのサンプルは、Springの公式のサンプルでさえ、この作業方法を示しています。

私の質問は次のとおりです。貧血ドメインモデルは依然としてアンチパターンと見なされていますか？私たち全員が（DDDに関して）間違ったことをしたことがありますか？リッチドメインモデルを持つことはSOLIDの原則に違反すると思いませんか？

ADMは、マイクロサービスなどの分散サービスのソリューションに適したパターンです。今日のWebベースのビジネスケースの多くに適合します。

Order Domainオブジェクトがあるかどうかを検討します。OOPアプローチでは、Order.Purchase（）Order.Cancel（）などを追加します。これは、メモリに注文を保持し、同じインスタンスに対して複数のことを行うデスクトップアプリでうまく機能します。

しかし、1つのこと、つまり注文のリストにアクセスして順番に購入するプログラム、または注文のリストを取得して順番にキャンセルするプログラムを使用する分散システムがある場合、同じオブジェクトに両方のメソッドがあると、センス。2つのドメインまたはバインドされたコンテキストが必要です。

PurchaseSystemOrder.Purchase()

そして

CancelSystemOrder.Cancel();

これらのオブジェクトが共有する唯一のものは、プロパティのデータ構造です。

マイクロサービスをどんどん追加していくと、何十種類もの注文ができてしまいます。これらのすべてのシステムによって処理されている同じ概念的な順序であっても、ドメインオブジェクトとしての注文について話すことはもはや意味がありません。

データだけをカプセル化し、それに応じてサービスの名前を変更する、貧血モデルであるOrderを使用する方がはるかに理にかなっています。

PurchaseService.Purchase(Order order)

これでOrderについて再び話し合うことができ、現在デプロイされている他のサービスに影響を与えることなく、処理するために考えている新しいサービスを追加できます。

FowlerとCoはモノリスシステムのバックグラウンドから来ています。彼らの世界では、ADMアプローチは、これらの個別のサービスすべてがメモリ内でインスタンス化され、OrderDTOが渡されて変更される単一のアプリを意味します。これは、メソッドをリッチなOrderモデルに配置するよりもはるかに悪いでしょう。

しかし、分散システムには多くのプログラムがあり、それぞれが単一のOrderメソッドのみを必要とし、それを複数のオーダーで実行し、それぞれをロードし、メソッドを実行してから破棄します。必要なのは、単一のサービスとデータオブジェクトのストリームだけです。

すべてのメソッドの要件と依存関係を心配して1つのメソッドを呼び出し、その後すぐにオブジェクトを破棄することで、リッチモデルを完全に生成しても意味がありません。

さらに、メソッドの1つを変更するには、すべての分散コンポーネントを更新する必要があります。これらのコンポーネントはすべて、ロジックがリッチモデルに依存しているためです。

コードベースに必要のないもののためのスペースがない

SOLIDとDDDは互いに直交しているため、実際には互いに異なる方向に進んでいます。同じコードベースに一緒に存在でき、おそらく存在する必要があるため、一方が他方の除外に慣れていると言ってはいけません。

貧血ドメインモデルがアンチパターンになるのは、問題のあるドメインに多くの動作があり、コピー貼り付けされたロジックや依存関係がたくさんある何百ものサービスメソッドがあり、サービスレイヤーメソッドが他のサービスレイヤーメソッドを呼び出して何かを実行する必要がある場合のみです。

DDDは、境界のあるコンテキストの概念により、マイクロサービスの優れたパラダイムです。

インフラストラクチャコードをドメインの一部として見る誘惑に注意してください。インフラストラクチャコードは、自分で作成したものではないもの、またはサードパーティのシステムと相互作用するフレームワークまたはライブラリに結合されたものです。データベース接続、SMTPメーラー、ORMライブラリ、アプリケーションサーバーランタイムなど、すべてがインフラストラクチャであり、回避できる場合はドメインに含めたり、依存したりしないでください。

SOLIDの原則は、より優れたOOPコードを作成するために使用できる一連の汎用OOP概念です。それらを使用して、優れたDDDコードベースを作成できます。

リッチドメインは、うまくやればいいです。ないときの悪夢。貧血ドメインは常に悪いです。しかし、お馴染みの快適な種類の悪い。

貧弱なドメインだけが必要な場合は、汎用言語を選択するときに間違った言語を選択します。第4世代の言語は、特定の用途に特化しています。貧血で十分であれば、それらを使用することで生活が楽になります。

多くのフレームワークは、Javaジョブとしてそのジョブをアドバタイズできなくなるまで、言語スペースに侵入します。これはJava / Springジョブです。彼らがやっていることは、あなたを彼らに依存させることのほかに、汎用言語を第4世代言語の卑劣な形に変えることです。

それはベストプラクティスですか、それともアンチパターンですか？まあ、あなたは上司がコードベースで作業するために人々を雇うことができるかどうかを気にするだけです。したがって、私たちが汎用言語を使って人を雇うふりをする必要がある場合は、そうします。

それで大丈夫なら、それで結構です。確かにあなただけではありません。

しかし、そうであるべきだと私に言わないでください。それ以上に私のために何かをしていると言わないでください。私はそれなしで生きる方法を知っています。私はそれを押し出す方法を知っているので、それに依存するものはほんの少しです。戦うのが難しいからといって、私に譲ってすべてを引き継がせるように頼んでいるなら、そうだと思う。

私のコードベースには、必要のないもののためのスペースがありません。

SOLIDと他の設計原則に関しては、貧血の領域でもそれらに大部分従うことができます。それらに従わないと、別の種類の問題が発生します。