DDDドメインモデルの問題

Question

は、私たちはこのシナリオを持っているパートナーと私の議論を持っています

私は決定しました： 値オブジェクトを持つPersonエンティティと残りのプロパティ。この方法では、Person（email、sex、dateofbird）に関する特定の情報にアクセスしたい場合は、パブリッシャーまたは広告主のルートエンティティを経由して取得する必要はありません（Personを集約ルートとして扱う）。

Sample: **Person.BillingAddress.Address1 : 
     Person.BillingAddress.Address2 : 
     Person.BillingAddress.POBOX : 
     Person.Email : 
     Person.Sex** 

私のチームメイトは、抽象クラスを使用してそれを行うにすることを提案、広告主およびパブリッシャーは、すべての一般的な性質を持つために人抽象クラスから継承します。

これを実行する最善の方法は何ですか？あなたが持っている場合は私たちをご案内ください。

おかげで、 ペドロ・デ・ラ・クルス

Answer 1

あなたは正しいと思います。継承は、その振る舞いが一般的である（あるものは他のもののようなものです）場合には意味をなさないので、プロパティは同じものであるためPersonは他のものではありません。それはコードの再利用ではありません。

Answer 2

あなたはすべきであるfavour composition over inheritance。

あなたの言語が複数の継承をサポートしている場合を除いて、この階層に何か別のものを導入する必要がある場合（例えば、ルートエンティティAuditableEntityを作成する必要がある場合）悪い）。

Answer 3

この場合、私は継承を気にしません。脆いと思います。

私は構図と役割に基づいたアプローチが好きです。管理者ロールは、Personオブジェクトをラップし、そのロールに関連付けられたすべての特殊な属性および動作を持つことがあります。

Answer 4

私は広告主と出版社が会社から継承されるべきだと思っています。会社には連絡先（またはあなたのケースの人）のコレクションが必要です。

技術的に会社は支店のコレクションを持つことができます。

各支店は住所を持つことができ、各連絡先（人）は住所を持つことができます。

Answer 5

（警告 - 過度に単純化した）この場合

継承がテスト「で」失敗..通常

あなたが求めるだろうが、私のクラス「」<whatever>「である」またはそれをしない「持っています」 a <whatever>

Answer 6

@ Scott人から継承する際の問題は何ですか？

@Timここでどのように継承が失敗しますか？

Personを抽象クラス、AdvertiserとPublisherを具象クラスとしましょう。このようにして、広告主は共通のプロパティを持ちます。これはパブリッシャーと同じで、今は人を渡すことができます。

広告主は人です。 パブリッシャーは人物です。私はあなたの質問を読んでいるとして、私は、継承に

Answer 7

私の2セント...

を好む、物理的な人物がモデルの一部ではないようです。あなたのモデルはパブリッシャーと広告主を扱います。

最初。私は、物理的な人（または会社）は、「階層またはパートナーリポジトリ」に変換できる分離した「階層参照」ドメインに住んでいなければならないと思います。

第2。あなたのモデルはパブリッシャーと広告主を必要とするので、私はDAL（そしてリポジトリがより小さな方法で）の責務であり、これらのエンティティを定義して作成する必要があると思います。 DALは物理的な人物アイテムを持っている必要がある唯一の場所です（モデル内のエンティティではないので「アイテム」と呼んでいます）。モデルから分離する必要があります。物理的な人物は、出版社とパートナーのエンティティの建設計画に含意されているため、データ側にとどまっていなければなりません。それらの実体を精製し、水和することは、貯蔵所になければならない。

私はあなたのモデルに "Person"クラスを持ってはいけないと思っています。あなたのモデルからは見えない、リポジトリの "真下"にあるべきだと思います。