3

OO/DDD スタイルでアーキテクチャを開発し、注文エンティティなどのドメイン エンティティをモデル化する場合、注文に関連するロジック全体を注文エンティティに入れます。しかし、アプリケーションがより複雑になると、Order エンティティはますます多くのロジックを収集し、このクラスは非常に巨大になります。貧血モデルと比較すると、明らかにアンチパターンですが、その巨大なロジックはすべて異なるサービスに分離されています。

巨大なドメイン エンティティを処理しても問題ないですか、それとも問題があることを理解していますか?

4

3 に答える 3

9

豊富なドメイン モデルを作成しようとしている場合は、エンティティをアイデンティティとライフサイクルに集中させ、プロパティまたは動作でエンティティが肥大化するのを避けるようにしてください。

ドメイン サービスは動作を配置する場所になる可能性がありますが、動作を値オブジェクトに割り当てた方が適切なドメイン サービス メソッドを多く目にする傾向があるため、動作をドメイン サービスに移動してリファクタリングを開始することはしません。ドメイン サービスは、現在のドメイン モデルの外部にあるものへの接続の前にある単純なファサード/アダプターとして最もよく機能する傾向があります (つまり、インフラストラクチャの懸念をマスキングします)。

アプリケーション サービスに動作を配置することもできますが、その動作がドメイン モデルの外部に属しているかどうかを自問してください。原則として、アプリケーション サービスは、エンティティ、ドメイン サービス、リポジトリにまたがるオーケストレーション スタイルのタスクに集中するようにしてください。

肥大化したエンティティに遭遇した場合、最初にすべきことは、まとまりのある一連のエンティティ プロパティと関連する動作のセットを探し、これらの暗黙の概念を値オブジェクトに抽出して明示的にすることです。その後、エンティティはその動作をこれらの値オブジェクトに委任できます。

私たちは皆、エンティティに慣れている傾向があるため、値オブジェクトが提供する不変性、カプセル化、および構成可能性の利点を得られるように、より柔軟な設計に向けて移動するように、値オブジェクトに偏るようにしてください。

値オブジェクトを使用すると、より機能的なスタイル (副作用のない関数など) をドメイン モデルに組み込むことができるため、エンティティは、ID とライフサイクルを管理する負担に複雑な動作を追加するという複雑さに対処する必要がなくなります。詳細については、Eric Evan のhttp://domainlanguage.com/ddd/patterns/および Blue Book にあるエンティティと値オブジェクトのパターンの概要を参照してください。

于 2012-10-15T16:27:43.577 に答える
6

OO / DDDスタイルでアーキテクチャを開発し、いくつかのドメインエンティティ、たとえばOrderエンティティをモデル化する場合、注文に関連するロジック全体をOrderエンティティに配置します。しかし、アプリケーションがより複雑になると、Orderエンティティはますます多くのロジックを収集し、このクラスは非常に巨大になります。

巨大になる傾向があるクラスは、多くの場合、重複する責任を持つクラスです。順序は、複数の責任を持つ可能性があり、アプリケーションでさまざまな役割を果たす可能性があるクラスの典型的な例です。

注文が表示されるコンテキストを考えると、それは可変状態のエンティティである可能性があります（つまり、交渉フェーズ中に注文の商業的状態を管理している場合）が、アプリケーションがロジスティクスを管理している場合、注文は異なる役割を果たす可能性があります。不変の値オブジェクトは、ロジスティックのコンテキストで最適な実装である可能性があります。

貧血モデルと比較すると、確かにアンチパターンですが、その巨大なロジックはすべて異なるサービスに分離されています。

...そして分離は良いことです。:-)

元のモデルはおそらくデータ中心であり、さまざまな目的（注文の作成、支払い、注文の履行、注文の配信）に役立つデータが同じコンテナー（Orderクラス）に積み上げられているように感じました。ここからは言えませんが、非常に頻繁なパターンです。このデータのすべてが同時に同じ目的に役立つわけではありません。

多くの場合、あなたが説明しているような肥大化したクラスは、境界コンテキスト間の分離の欠如、および/または同じ境界コンテキスト内の不完全な集約分離の匂いです。私は見てみたいと思います：

  • 一緒に変わるもの;
  • 同じ理由で変わるもの;
  • 行動を遂行するために必要な情報。

それに応じて集計境界を再定義してみてください。そしてまた：

  • アプリケーションのさまざまな目的。
  • さまざまな利害関係者。
  • さまざまな暗黙のモデル/言語。

関係するコンテキストを発見することになると。

大規模なアプリケーションでは、複数のモデルが存在する可能性があるため、少なくとも多くの役割を果たしている概念については、単一のドメイン概念の複数の表現につながる可能性があります。

これは、ポールのアプローチを補完するものです。

于 2012-10-15T17:10:36.843 に答える
3

DDD でサービスを使用しても問題ありません。通常、サービスはドメイン、アプリケーション、またはインフラストラクチャ レイヤーで表示されます。

エリックは、サービスをいつ使用するかを判断するために、彼の著書で次のガイドラインを使用しています。

  • 操作は、ENTITY または VALUE OBJECT の自然な部分ではないドメインの概念に関連しています。
  • インターフェイスは、ドメイン モデル内の他の要素に関して定義されます。
  • 操作はステートレスです
于 2012-10-01T08:01:51.903 に答える