ddd - バリューオブジェクトを正しく識別する方法

私はエンティティをモデリングしており、これを長い間苦労しています。ここに私のPersonエンティティです：ddd - バリューオブジェクトを正しく識別する方法

Person 
    ID 
    Name 
    Email 
    Password 
    City 
    Phone 
    Biography 
    Rating 
    Description

私は値オブジェクトに、これらのプロパティを分割しようとしましたが、これまでのところ、私は唯一のVOに変換することができました（たとえば、市は都市名でVOを作っています、および国名）。

たとえば、EmailとPasswordを合わせてVOを作成すると、VOはCredentialsになりますか？私はVOsの分離に行き過ぎでしょうか？

すべてのヘルプは大幅に

を高く評価している[EDIT]

いくつかの議論の後、最善の解決策がでグループ化する必要があるメールとパスワードを除いて、それ自身のVO内のすべてのプロパティを維持することであることが表示されます「資格証明」VO。

出典

2016-07-20 Lucio

値オブジェクトは、それらを一意に識別する値です。等価性は、一意性を提供するための明示的なプロパティ（IDなど）ではなく、値によって行われます。すべてのフィールドが等しい場合、2つの値オブジェクトは等しいです。

ドメインの専門家が使用する言語に従ってください。人々を論じるとき、彼らはどのような言葉を使うのですか？彼らは資格情報、または電子メールとパスワードを参照していますか？

また、常に一緒に使用されるプロパティのグループを特定します。パスワードは必ずメールと一緒に使用されている場合たとえば、それはあなたがそこ動作をプッシュすることができますとしての資格情報で彼らは、オブジェクトのグループに理にかなっている（すなわちCredentials.Validate（））

[UPDATE]

のすべて次のプロパティは、値の候補があなたは

名前

があるの最小/最大VALUを施行する必要が不変条件に応じて、オブジェクトされています名前のために？
許可されていない文字はありますか？

メール

それは有効なEメールアドレス
である2人は、同じメールアドレスを持つことができますか？

パスワード

最小/最大の長さは？
必要な文字は？
無効な文字はありますか？

電話

は、それが有効な電話番号のですか？
どのように国際ダイヤルコードを扱いますか？

評価

は、評価のために許可される最小値と最大値はありますか？
どのように計算されますか？（それが計算されますか？）

説明

伝記

市など

....

あなたは上記のための値オブジェクトを作成した場合intやstrなどのプリミティブ値を使用する代わりに概念値オブジェクト内にビジネスルールをカプセル化することができます。

2つのことをまとめて使用する場合、電子メールとパスワードを資格証明値オブジェクトに組み合わせることができます。クレデンシャルなどでログインする... Credentialsオブジェクトの外部でメールを使用する必要がある場合は、Credentials.Emailにアクセスできます。

出典

2016-07-20 13:09:46 tomliversidge

問題は、私はこのプロジェクトでDDDに歯をつけていることです。私はソロで作業しているので、私はドメインの専門家でもあり、開発者でもあります。ユビキタス言語 – Lucio

2番目のアプローチを試してください。よく一緒に使用されるもの – tomliversidge

問題は、一部のフィールドが他のフィールドなしで使用できるということです。あなたの例を挙げると、電子メールはパスワードなしで使用することができ、例えばプロファイルページに表示することができます。それが私がこれに苦しんでいる理由です。 – Lucio

あなたが持っているものは、疑いなくデータ構造（CRUD）として考えられます。適切なDDDでは、 "Create Person"のようなビジネスケースから始めて、のという概念を表すというモデルを見つけます。

モデルは、コンポーネントとビジネスルールのグループによって定義されます。あなたのコンポーネントは通常、VOです。これは、明示的なIDなしで単純または複合の値として表現できるマイナーな概念を表すモデルであり、特定のビジネス制約をカプセル化しているためです。たとえば、Email VOでは、有効な電子メールの価値があることを確認します。

より大きなVOを作成することが理に適っているかどうかをドメインに知らせる必要があります。通常あなたはVOで始まり、はを発見します。それは他のVOから構成されています。一般的に、我々はトップダウンに行く。モデリングの例はsee hereです。

ドメインエキスパートがいない場合でも、ビジネスケースで考えることができ、各ケースごとに特定のモデルを特定できます。主にシンプルな構造といくつかのデータ検証ルールで終わると、おそらくCRUDアプローチを使うだけの簡単なドメインしかないでしょう。

出典

2016-07-20 15:32:55 MikeSW

リンクアカウントのモデリングの例では、口座残高を超過してはならない不変量はどのように実装される？あなたはこれのために読んだモデルに頼って、最終的に一貫していますか？金額にはある程度の制限があるため、多額の金額を補償する必要はありません。 – plalx

@plalxあなたが言うことは、転送サービスではなくドメインサービスの一部です。 TransferはAccountBalanceについて知らない。ビジネスルールは、より高い金額を可能にすることができます=>あなたは素晴らしい超過手数料を得るか、それを防止します。しかし私の例は、ビジネスケース全体ではなく、集約のみに焦点を当てていました。 – MikeSW

私が言っていることは、当座借越取引を防止する方法がないことです。なぜなら、転送は唯一の集計であり、残高の概念はないからです。極端に高い当座貸越を避けるために、1日に1000ドルまでの勘定振替額を超えたとします。誰かが複数の同時転送要求を実行して競合状態を悪用し、したがって1日あたり1000ドルを累積的に上回るシナリオをどう対処しますか？私はこれが銀行の分散した性質のために銀行が従わなければならないモデルだと思うが、不変物を公開したままにしておくことは、当座貸越を防ぐよりはるかに複雑である。 – plalx

特定のドメインモデル構造を適用しないでください。ユースケースの観点からドメインモデリングにアプローチする必要があります。

電子メールとパスワードをCredentials VOにまとめることで、より大きなVOを作成する必要がありますか？

2つを一緒に使用する傾向がある場合にのみ、これを実行してください。彼らがいなければ、それらを一緒に残しても問題ありません。

サポートする必要がある不変条件の数が新しい概念の導入を正当化するのに十分高い場合、単一のプロパティを独自の値オブジェクトに抽出することが理にかなっていることに注意してください。詳細はthis articleをご覧ください。

出典

2016-07-21 21:17:39 Vladimir

ddd - バリューオブジェクトを正しく識別する方法

答えて

関連する問題