16

最近、注目を集めた「貧血ドメインモデルパターン」の投稿を読みました。これを読んでいると、貧血ドメインモデルの説明が、私が取り組んで構築したプロジェクトの多くに適用されていることがわかりました。非常に自然に感じたので、これを悪い設計上の決定だとは思いませんでした。ドメインモデルが軽量でそれほど複雑ではない場合、AnemicDomainModelモニカは非常によく合うと思いました。「貧血ドメインモデル」のタイトルがコードを適切に説明していないのに、ドメインモデルに複雑さを加える必要がないのはなぜですか。

質問：どの時点で、コードの複雑さをサービス/アプリケーションレイヤーに詰め込むことが正しくなくなり、代わりにエンティティオブジェクトの複雑さを明らかにすることになりますか？私はすべて、エンティティに「合計」プロパティを持っていて、内部で合計の値を把握できるようにしています。私は、エンティティを他のさまざまなウィジェットと直接通信させて、そのプロパティの1つの結果を決定するためのものではありません。では、貧血ドメインモデルの概念は、アンチパターンですか、それとも関心の分離ですか？タイトルの貧血ドメインモデルは常に悪いことですか？

このデザイン（アンチ）パターンについて他の人の考えがどうだったか興味があります。

4

3 に答える 3

9

ドメインが軽量である場合（読み取り：複雑ではない）、推奨されるアプローチは、コアドメインレイヤーで単純なActiveRecordタイプのオブジェクトを使用することです。通常、DBテーブルとドメインオブジェクト間の1対1のマッピングであり、ここには多くの「ロジック」はありません。アプリは、データベースとUIの間でレコードをシャッフルし、単純なCRUD操作を可能にします。

複雑なドメインの場合、一部のオブジェクトが最終的にDBテーブルにマッピングされ、一部のオブジェクトは単純なデータ以外のドメイン内の他の概念を表さない可能性が高いコアドメインモデルを構築します。アプリケーションのロジックは、適切な場合はオブジェクト内に、複数のドメインオブジェクト間の調整が必要な場合はサービスオブジェクト内に配置する必要があります。

貧血ドメインモデルのアンチパターンは、複雑なドメインがある場合に適用されますが、ドメインオブジェクトにロジックを適切に配置し、サービスにロジックを配置する代わりに、すべて（またはほぼすべて）のロジックをコアドメインオブジェクトの外部に配置します。

ここでの主な違いは、ロジックを配置する場所です。あまり持っていない場合は、明らかにドメインオブジェクトは単純なデータコンテナにすぎないように見えます。複雑なロジックがある場合は、ドメインオブジェクトからすべてを引き出すだけでなく、コアドメインオブジェクトとドメインサービスの間で適切に分離します。

于 2009-07-21T00:23:15.073 に答える
9

重要な質問は、ドメイン モデルが貧血である理由を尋ねることです。

  • 主にCRUD 画面の集合体であるアプリケーションのように、ビジネス ロジックがほぼ完全に欠如しています。
  • 「ドメインオブジェクト」が実際には単純な構造の データ転送オブジェクトであるサービス指向アーキテクチャ?
  • コードの所有権や前方/後方互換性など、リファクタリングを過度に妨げる政治的または実用的な考慮事項はありますか?
  • オブジェクト指向言語で手続き型/リレーショナル設計を適用しますか?

いずれにせよ、ドメイン モデル ロジックとサービス ロジックの境界について簡単な経験則を選ぶとすれば、「外部の世界」(ユーザー インターフェイス、 Web サービスなど) は、おそらくドメイン モデルに属していません。

于 2009-09-08T22:13:57.363 に答える
1

こんにちは！

ロジックをドメイン オブジェクトの外に置くと、オブジェクト指向の主な概念の 1 つ、カプセル化 (またはデータの隠蔽) が完全に失われます。

AOP はそれをある程度補っていますが、結局のところ、オブジェクト指向の重要な概念の 1 つが失われています。

よろしく、ステファン

于 2009-09-08T21:42:25.867 に答える