5

2 つの集約ルートを持つ「ディレクトリ」境界コンテキストがあるとします。会社と人。会社には、いくつかの追加の値データを含む個人集計の ID を保持する子エンティティ「Position」のコレクションがあります。

すべて良い。

次に、集約ルート JobAriticle を使用して「Article」境界コンテキストを追加します。これには、会社のポジションからマッピングされた Contact 値オブジェクトが必要です。

集約ルートのみを参照する必要があることを知っていれば、どうすればよいでしょうか? 会社とポジションの関係に不変条件があると仮定して、集計を分割したくありません。会社 ID と役職 ID の両方を使用して、腐敗防止レイヤーを介して役職をマッピングしても問題ありませんか? それとも、会社の集計をバラバラにする必要がありますか。

4

1 に答える 1

8

Position「Article」境界コンテキストのユビキタス言語で意味のある概念である場合、「Article」境界コンテキストPositionの ValueObject または Entity である必要があります。

Contactそれが「記事」の境界付けられたコンテキストでは意味のある概念であるが、「ディレクトリ」の境界付けられたコンテキストと何らかの形で関連付ける必要があると言っている場合はPosition、その関連付けの目的は何かを考える必要があります。

  • で連絡先を作成する前に、ポジションが存在することを確認する必要がありJobArticleますか?
  • Positionと の間で同期が保たれる共有データはありContactますか?
  • ポジションがアーカイブ/削除された場合、またはその他の方法で使用できなくなった場合はどうなりますか? すべての連絡先に対して何かを行う必要がありますか?

関連付けられた連絡先を作成する前にa が存在することを確認する必要がある場合Position、記事コンテキストの責任において暗黙的に位置が役割を果たすため、記事コンテキストで新しいPositionエンティティを作成して同期を維持したくなるでしょう。

PositionCorrelationどちらの方法でも、Article コンテキスト内の何かを Directory コンテキスト内の対応するエンティティと関連付けるには、次の2 つのプロパティを持つ「Article」コンテキストで ValueObject を作成できます。

  1. CompanyId (グローバルに一意)
  2. PositionId (社内でローカルに一意)

集計は他の集計ルートのみを参照する必要があるというルールは、集計内のエンティティを識別するための情報も提供できないという意味ではありません。これは、他のエンティティとやり取りしたい場合は、集約ルートを介して行う必要があることを意味します。つまり、少なくとも集約ルート ID が必要です。次に、ローカル Id を使用して会社にそのポジションの 1 つに対して何かを行うように依頼する場合、それは問題ありません。

ただし、このアプローチに従うと、「記事」の境界付けられたコンテキストに「位置」という用語が導入されることに注意してください。これにより、「記事」のコンテキストで「位置」という単語が別の何かを意味する場合、名前の衝突が発生する可能性があります。おそらく、記事内の位置 (段落番号など) を意味します。この場合、クロスコンテキスト識別子を何と呼ぶか​​を慎重に検討する必要があります。

1 つのアプローチとしてPosition、 と 1 対 1 のマップがある場合Contact、2 つのプロパティを次のようにすることができます。

  1. 会社ID
  2. 会社の連絡先 ID

また、コンテキスト間の統合時に Anti-Corruption Layer (ACL) で同期を維持する場合は、CompanyContactId と PositionId (Company 内のローカル) の値を同義として定義します。これにより、各 UL の内部的な一貫性が維持され、ACL で 2 つの間の相関が定義されます。

于 2016-11-07T05:07:28.687 に答える