境界のあるコンテキストとサブドメインについて混乱している
私はエリック・エヴァンの本を読み、ヴォーン・ヴァーノンの本を今読んでいます。私は第2章でサブドメインと境界のあるコンテキストについて話していますが、今は完全に混乱しています。
私が蒸留できたことから、BCとSDの間には1対1の関係があるはずです。しかし、私は他の場所でこれが必ずしもそうではないことを読みました。
誰かが私にBCとSDの関係を説明できますか？
サブドメインはビジネスの一部です。コアドメイン、サポートドメイン、および汎用ドメインがあります。コアドメインはお金のある場所であり、サポートドメインはコアビジネスをサポートし、ジェネリックドメインは必要なものですが、あまり気にする必要はないので、おそらく購入するでしょう。保険会社の場合、コアドメインは保険、サポートドメインはクライアントポートフォリオ、汎用ドメインはタイムシートのようなものです。
一般に、境界付きコンテキストは、ユビキタス言語が一貫している境界です。 DDD walhallaでは、各サブドメインは独自の境界付きコンテキストに存在します。しかし実際には、レガシーがあります。すべてを一度に実行しようとするパッケージがあります。これにより、あらゆる種類のawkard関係が強制されます。
私は理解してこれらの概念を説明しようとします。
DDDでは、技術チームとビジネスチームが同じ用語を使用し、問題について同じ意見を持つことができるように、すべてをユビキタス言語で伝達する必要があります
- ドメイン DDDでビジネスの実際の問題を表します。など：Eコマースはドメイン、給与計算システムはドメインです
- ドメインは多くのサブドメインに分割されているため、各サブドメインは小さな問題に焦点を当てています。など：Eコマースには、ショッピングカート、請求、製品カタログ、顧客情報など、多くのサブドメインがあります...
- 各サブドメインには明示的な責任が必要であるため、機能を制限する境界があります。境界は、サブドメインが1つのことだけを行い、うまくいくように集中するのに役立ちます。この境界は、サブドメインのbounded contextと見なされます。制限されたコンテキストは以下を定義します：
- サブドメインにはいくつのドメインモデルが必要ですか？
- 各モデルにどのプロパティが必要ですか？
- サブドメインで必要な機能はどれですか？
例：ショッピングカートサブドメインには、モデル：カート、製品、顧客情報...が必要で、カートでCRUDを実行する機能が含まれています。注：ショッピングカートサブドメインの製品および顧客モデルは、製品カタログおよびカスタマープロファイルサブドメインのモデルとは異なる場合があり、ショッピングカートに表示するために必要なプロパティのみが含まれています。
ブルーブックの予約コンテキストを18回読み直すことで、ようやくハンドルを握ることができました。 http://codeidol.com/csharp/domain-driven-design/Maintaining-Model-Integrity/Bounded-Context/
この記事も役立ちました： http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/
this をご覧ください。バウンドコンテキストですか、それともコンテキストですか？コンテキストという用語は概念のグループ化の一般的な説明であり、境界コンテキストという用語はより具体的です。境界コンテキストとは、境界を明示的に定義し、独自のモデルを持ち、独自のコードを維持するアプリケーションの領域です。有界コンテキスト内では、すべてが厳密に一貫している必要があります。
通常、コンテキストとバウンドコンテキストという用語は同じ意味で使用できますが、ビジネスの側面についてはコンテキスト、技術的な実装についてはバウンドコンテキストという用語で説明する傾向があります。