3

私はDDDの概念に比較的慣れていないため、比較的単純なシナリオで境界付けられたコンテキストを定義する方法を説明する例がたくさんあることに気づきましたが、カバーされていないように見える領域の1つは、マスターデータと参照データです.

ここで言及している参照データの種類は、通貨コード、国コード、および測定単位であり、有効な値のみが使用されるようにするために使用されます。

私が言及しているマスター データの種類は、顧客や製品などのエンティティであり、異なる境界付けられたコンテキストがエンティティの独自の視点を持つ必要はありません。一部のシナリオでは、請求の境界付けられたコンテキストの顧客エンティティは、出荷の境界付けられたコンテキストの顧客エンティティとは異なることを理解していますが、この質問の目的のために、請求と発送の両方にまったく同じ顧客データが必要であると想定できます。

私の質問は、複数の境界付けられたコンテキスト (ERP システムなど) を持つアプリケーションで、マスター データと参照データを共通の境界付けられたコンテキストで定義するか、まったく同じデータが含まれている場合でも、これらのエンティティを各境界付けられたコンテキストで複製する必要があります。 ?

4

2 に答える 2

2

さまざまな DDD の本では、ドメイン モデルのこの共有サブセットを持つことを と呼んでいShared Kernelます。ドメイン モデルを共有することの主な問題は、2 つ以上のソフトウェア チームがそれぞれ異なる境界付けられたコンテキストで作業している場合、共有カーネル内の何かを更新したい場合、変更の副作用について他のチームと合意しなければならないことです。また、他の境界付けられたコンテキストからの用語やアーティファクトで、他の境界付けられたコンテキストを汚染します。

たとえば、請求チームがエンティティにLoyaltyDiscountPercentageプロパティを追加したい場合、Customerこのドメイン エンティティを共有する他のチームは、独自の境界コンテキストに関連しないこのプロパティを受け入れる必要があります。Customer実体はすぐに多くの別個の境界付けられたコンテキストからアーティファクトを拾い上げ、単一のコンテキストで顧客を説明することができなくなります。

于 2015-03-25T13:47:53.993 に答える