design-patterns - ドメイン モデル オブジェクトに必要なロジックの量

Question

Greg Young によるこの投稿を読み終えたところです。彼は、Microsoft がダム データ転送オブジェクトを使用して推奨するパターンについて語っています。彼は、Java コミュニティでは物事が逆方向に進んでいることをほのめかしました。

私の質問は、エンティティ オブジェクトにどの程度のロジックを含める必要があるかということです。私が働いている場所 (C# ショップ) の哲学は、シリアル化できない場合は、エンティティに入れないことです。

Answer 1

それらを「ドメイン モデル オブジェクト」と呼んでいる場合は、Fowler のドメイン モデル パターンを参照していると想定します。http://martinfowler.com/eaaCatalog/domainModel.html

その仮定を考えると、それは本質的にパターンの定義であるため、質問に対する答えは「すべてのビジネスロジック」です。

残念ながら、「ドメイン モデル」という用語は最近、動作のないデータのオブジェクト モデルのみを意味するように骨抜きにされたようです。

まだ読んでいない場合は、PoEAA を読んで、そのドメイン ロジックが自分の状況のどこに属していると思うかを判断することをお勧めします。ドメイン モデルを決定する場合は、Evan の DDD の本を読んで、エンティティ、値オブジェクト、およびサービスの違いについて学ぶことをお勧めします。

それが役立つことを願っています!

Answer 2

最近、私は、構造を持ち、そのモデルに共通の動作 (つまり、複数の境界付けられたコンテキストで使用できる動作) のみを持つドメイン モデルを作成し、境界付けられたコンテキストに固有の動作の拡張メソッドを作成するというアイデアをいじっています。 . これにより、ドメイン モデルが DTO に近くなり (それが好きな場合)、そのドメイン モデルの使用が制限されたコンテキスト内で許可された動作のみに制限されます。したがって、それは中途半端な対応のオプションになる可能性があります。:)

Answer 3

私が理解している限り、エンティティに関連するすべてのビジネス ロジックはそのエンティティに入る必要があります。これは、システムのビジネス ルールに基づいてエンティティの動作または内部構造を定義するロジックで構成されます。これには、プレゼンテーション ロジックや永続化ロジックを含めるべきではありません (アクティブ レコード デザイン パターンは明らかな例外です)。モデル化しようとしている世界のもの。

私が見ようとしている方法は、モデルをできるだけ再利用できるようにすることです。クライアント コード (またはエンティティを使用するコード) が異なる可能性がある別のシステムにモデルを移植する場合、モデルがどのように使用されるかを常に考えてみてください。機能がエンティティの一部でない場合でも、同じビジネス ルールに従って同じように動作しますか? 答えが「いいえ」の場合、機能はエンティティに含まれる必要があります。