12

Shipping ContextとBilling Contextという 2 つの境界付けられたコンテキストがあるとします。これらの各コンテキストは、顧客について知る必要があります。

CustomerTblデータ レベルでは、顧客はデータベース内のテーブルによって表されます。このテーブルは、顧客を説明するために必要なすべての列で構成されています。

列CustomerTbl(簡略化):

  • Name
  • PhysicalAddress
  • PaymentMethod

Shipping Contextは と に関係し、NameBillingコンテキストはと に関係します。PhysicalAddressNamePaymentMethod

Shipping Contextでは、集計をモデル化しましたRecipient。

  • Recipientと のプロパティ/値オブジェクトが追加されましNameたPhysicalAddress

請求コンテキストでは、集計をモデル化しましたPayer。

  • Payerと のプロパティ/値オブジェクトがNameありますPaymentMethod

RecipientとPayer集約の両方は、コンテキスト境界によって完全に分離されています。また、独自のリポジトリもあります。

質問:

  1. 同じ「データベース テーブル」を使用して、複数の集計 (それらが別々の境界付けられたコンテキストにある場合) を持つことは許容されますか?

  2. 顧客データは、より多くの限定されたコンテキストで必要になる可能性があります。これは、境界付けられたコンテキストごとに多くの集約、リポジトリ、およびファクトリの実装を意味するのではないでしょうか? コードにはある程度の冗長性があります。これは保守性に影響しませんか？

  3. 集約間でプロパティを共有することは許容されますか? 例として、顧客のNameプロパティがあります。これは冗長な検証コードを意味しますか?

4

2 に答える 2

9

質疑応答

1) 同じ「データベース テーブル」を使用して複数の集計を行うことは許容されますか?

  • 共有状態を管理するための厳密な戦略に従っている限り、私には受け入れられます。
  • ドメインはデータよりも重要であると考えられているため、DDD には受け入れられます。
  • (多すぎる) 隠れたコストを導入することなく仕事を成し遂げる限り、それは顧客に受け入れられます。

2) 顧客データは、より多くの限定されたコンテキストで必要になる可能性があります。これは、境界付けられたコンテキストごとに多くの集約、リポジトリ、およびファクトリの実装を意味するのではないでしょうか? コードにはある程度の冗長性があります。これは保守性に影響しませんか？

必ずしもそうとは限りませんが、共有カーネル パターンを見てください。

3) 集合体間でプロパティを共有することは許容されますか? 例として、顧客の Name プロパティがあります。これは冗長な検証コードを意味しますか?

質問 1 と同じ答えです。冗長性に関しては、共有カーネルがあれば、そこにバリデータ クラスを配置するだけで済みます。

DRY と DDD の競合について:

エレガントなコードは、優れた設計原則を不必要に互いに対立させることはありません。通常、原則を満たす方法があります。原理を十分に理解していないか、問題を十分に分析していないため、まだ見つけていないだけです。

(これが独断的に聞こえるのは、ソフトウェア エンジニアリングが実際には宗教だからです)

于 2014-02-07T06:48:50.127 に答える
4
于 2014-02-07T04:26:44.717 に答える