2

システムに Orderdomain と Customerdomain という 2 つのドメインがあるとします。

どちらのドメインもかなり複雑で大きいため、1 つのドメインに統合することはできません。

しかし、それらの間にはビジネス上の関係があります。各注文で、顧客は注文者として行動します。

私の頭の中には、少なくとも 3 つの解決策があります。

  1. Order と Customer の両方で、customerId をプリミティブ型として格納します。

  2. OrderDomain.CustomerId と CustomerDomain.CustomerId の 2 つの値オブジェクトを作成します。これらの型が等しいかどうかを比較できることを確認してください。

  3. valeobject CustomerId を使用して 3 番目のコンポーネント「SharedValueObjects」を作成し、そのタイプを両方のドメインで使用します。

どちらが優先されますか、それとも 4 番目に優れたものを考え出すことができますか?

4

1 に答える 1

4

値オブジェクトに関する一般的な質問と、コメントからのより具体的な質問の両方に答えようとしますか?

  1. ドメインは値オブジェクトを共有できますか?

場合によります。私が現在取り組んでいるシステムには、15 ほどの大規模なサービスがあり、「EMailAddress」、「PhoneNumber」、「Money」などの値の型を共有しています。これらの型は明確に定義されており、共有の問題はありませんが、他の場所で使用される可能性があるという理由だけで物を共有するのではなく、実際に使用されているものに共有された値のタイプを味わってください。共有するときは、システム全体の結合の代償を払います。

  1. 顧客と注文の間の関係を、キーをラップする値オブジェクトとして公開しますか?

いいえ、他の人が指摘しているように、顧客は注文ドメインで働いている誰かが知っていて、そこからのデータを必要とするものです。「顧客」と「注文」が2つの異なるドメインを表していると主張する場合、「顧客」ドメインはCRMデータのようなものだと思い込んでいますか? 「顧客」と「注文」を別々にモデリングしている場合、「顧客」ドメインには、「注文」ドメインで必要なデータ (請求先住所など) を含めることができません。密結合と巨大なオブジェクト グラフに対するあなたの反対意見は理解できますが、システムで複数の「顧客」エンティティを許可することでこれを処理できます。各「顧客」は、境界付けられたコンテキスト内で独自のデータと動作のセットを表します。例えば、CRMドメインにCustomerエンティティと「Order」ドメインにCustomerエンティティの両方を持つことができます（「Order」はカプセル化された一連のビジネスプロセスではなくエンティティのように聞こえるため、実際にはOrderingドメインだと思います）。CRMドメインでは、顧客は電話番号、連絡担当者、住所などを持っている可能性があります。「注文」ドメインでは、顧客は確かに注文を持ち、請求先住所などを持っています。要約すると: すべてを持っている顧客を作成しないでください。それを独自のドメインに配置し、注文との関係を削除します。オブジェクト グラフのサイズを縮小するだけです。ビジネス プロセスのカプセル化されたセットではなく、エンティティのように聞こえます)。CRMドメインでは、顧客は電話番号、連絡担当者、住所などを持っている可能性があります。「注文」ドメインでは、顧客は確かに注文を持ち、請求先住所などを持っています。要約すると: すべてを持っている顧客を作成しないでください。それを独自のドメインに配置し、注文との関係を削除します。オブジェクト グラフのサイズを縮小するだけです。ビジネス プロセスのカプセル化されたセットではなく、エンティティのように聞こえます)。CRMドメインでは、顧客は電話番号、連絡担当者、住所などを持っている可能性があります。「注文」ドメインでは、顧客は確かに注文を持ち、請求先住所などを持っています。要約すると: すべてを持っている顧客を作成しないでください。それを独自のドメインに配置し、注文との関係を削除します。オブジェクト グラフのサイズを縮小するだけです。

于 2012-02-06T18:52:50.647 に答える