9

私はドメイン駆動設計に精通しておらず、最近、プロジェクトのドメイン モデルの作成を開始しました。私はまだ ORM を決定していません (ただし、NHibernate を使用する可能性があります)。現在、値オブジェクトがまさにそれであることを確認しようとしています。

たとえば、「好きな」用語をカプセル化する以外にほとんど動作のない VO がいくつかあります。

public class Referral {
    public Case Case { get; set; } // this is the a reference to the aggregate root
    public ReferralType ReferralType { get; set; } // this is an enum
    public string ReferralTypeOther { get; set; }
} // etc, etc.

この特定のクラスには、2 レベル上の「Case」への参照があるため、Referral にアクセスする場合は、次のようにできます。ケース内にあり、ソーシャル内に単一の紹介があります)。入力しながら見ていると、Social エンティティを介してアクセスできるため、Referral に Case は必要ないと思いますよね?

さて、これが VO であるべきものであることは間違いありません。これをデータベースに永続化するために使用する予定の方法は、NHibernate にサロゲート識別子を割り当てさせることです (これについてはまだ明確ではありません)。 、誰かがそれについても詳しく説明してくれれば、それは私を助けてくれるでしょう。なぜなら、サロゲート識別子が私の VO にすでに Id を持っている必要があるのか​​ 、それとも Id なしで動作できるのか分からないからです)および/または保護された Id プロパティこれは、Referral クラスの外部に公開されることはありません (DB に永続化するという唯一の目的のため)。

タイトルの質問に移りましょう: VO にはコレクション (私の場合はリスト) が含まれている必要がありますか? これはデータベース内の 1 対多の関係としか考えられませんが、ID がないため、クラスをエンティティにするのは適切ではないように思われました。以下はコードです：

public class LivingSituation {
    private IList<AdultAtHome> AdultsAtHome { get; set; }
    public ResidingWith CurrentlyResidingWith { get; set } // this is an enum
} // etc, etc.

このクラスには現在 Id がなく、AdultsAtHome クラスには固有の型 (string、int) しかありません。したがって、これがエンティティであるべきなのか、それとも VO のままでいられるのかはわかりません。独自のテーブルとプライベート/保護された Id フィールドを使用して、これに 1:m の関係を使用するように ORM を構成する必要があります。 ORM は DB に永続化できます。

また、クラスごとに正規化されたテーブルを使用する必要がありますか? エンティティまたは値オブジェクトに割り当てられたクラスの複数のインスタンスを持つ可能性がある場合、および/またはそれらのオブジェクトの一部とコレクション 1:m 関係を持つ可能性がある場合にのみ、クラスごとにテーブルを使用する必要があると思います. 固有の型を持つ特定の値オブジェクトに対して単一のテーブルを使用しても問題はありませんが、ネストされた型では、正規化されたテーブルを使用する方が有利だと思います。これについても何か提案はありますか？

複数の質問で非常に冗長になって申し訳ありません：

1) 値オブジェクトにサロゲート識別子 (NHibernate など) が必要ですか?

2) #1 が「はい」の場合、値オブジェクトが概念上値オブジェクトとして「維持」されるように、これを非公開/保護する必要がありますか?

3) 値オブジェクトは他の値オブジェクト (リストなど) を持つことができますか、それともエンティティを構成しますか? （これに対する答えはノーだと思いますが、先に進む前に確認したいと思います。）

4) 集約ルートから数レベル下の値オブジェクトから集約ルートへの参照が必要ですか? (私はそうは思いません。これは、モデルを作成する際の私の見落としである可能性があります。同意する人はいますか?)

5) ORM に単純な値オブジェクトのマッピングを行わせながら、特定のもの (入れ子になった型やコレクションを持つ型など、1:m 関係のために独自のテーブルが必要になるプロパティ) に正規化されたテーブルを使用しても問題ありませんか?私のエンティティに属する同じテーブルに？

再度、感謝します。

4

1 に答える 1

12

こことここで関連する質問への回答を見てください

1)はい - VO を独自のテーブルに保存している場合

2)プライベート/保護された ID プロパティを使用できる場合は、すばらしいことです。または、明示的なインターフェイスを使用して ID プロパティを「隠す」こともできます。

しかし、あなたの質問を読んで、ID プロパティを見た開発者は、オブジェクトがエンティティであると自動的に想定することを示唆していますか? もしそうなら、彼らは（再）訓練が必要です。

3)はい、できますが、次の制限があります。

  • かなり珍しいはず
  • 他のVOのみを参照する必要があります

また、これを考慮してください: VOは固執すべきではありません。必要なたびに VO 全体を再作成するのは簡単/効率的ですか? そうでない場合は、エンティティにします。

4) Aggregate Lockingをどのように実装するかによって異なります。Ayende のソリューションを使用する場合、答えはイエスです。それ以外の場合は、オブジェクト グラフをトラバースして Aggregate Root に戻すメカニズムが必要になります。

5)はい。DDD はPersistence Ignorantであることを忘れないでください(理想的な世界では!)。

でも...

Referral はEntityであるべきだと思います。次の会話を想像してください。

会話 1:

  • トム：「ヘイ、ジョー​​！デビッド・ジョーンズの紹介をくれない？」
  • ジョー：「どれ？」
  • トム：「すみません、紹介番号123のことです」

会話 2:

  • トム：「ヘイ、ジョー​​！デビッド・ジョーンズの紹介をくれない？」
  • ジョー：「どれ？」
  • トム：「どうでもいいから、いくらでもくれ」

会話 1 は Referral がEntityであることを示唆していますが、会話 2 はそれが VO であることを示唆しています。

もう1つ:Referral.ReferralType存続期間中に変更されますか(エンティティである必要があるという別のヒントがあります)? 変化しない場合は、ポリポーフィズムの使用を検討し、NH に処理させます。

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

于 2009-11-30T08:23:46.117 に答える