1

私の現在のプロジェクト (e コマース Web サイト) では、チェックアウト プロセスでの請求、配送、支払いなど、さまざまな境界コンテキストがあります。

これに加えて、顧客が何を購入するかによって、チェックアウトのプロセスが異なります。そのため、彼女のカートの内容によっては、チェックアウト プロセスのステップ数が異なる可能性があります。または、特定の情報を尋ねることはありません。

では、異なる種類のチェックアウト プロセスごとに異なる境界付けられたコンテキストを作成する必要がありますか?

たとえば、Order 集計ルートは、チェックアウト プロセス EticketsOrder によって異なります (このコンテキストでは、配送先住所は必要ないため、ユーザーには尋ねません)。

ClothingOrder (このコンテキストでは、配送先住所が必要であり、これを取得するためのチェックアウト プロセスに追加の手順があります)

この分離は、2 つの異なるドメイン エンティティが類似のプロパティを持っているとしても作成されることを意味します。

この種の問題をモデル化する最良の方法は何ですか? コンテキスト境界を見つける方法は?

4

2 に答える 2

5

境界付けられたコンテキストは、主に言語の境界です。ブルーブックからの引用 (強調表示された重要な部分):

BOUNDED CONTEXT は、特定のモデルの適用可能性を区切るので、チーム メンバーは、何を一貫させる必要があるのか​​、またそれが他の CONTEXT とどのように関連するのかについて、明確に共有された理解を得ることができます。その CONTEXT 内で、モデルを論理的に統一するように作業しますが、それらの境界外での適用可能性について心配する必要はありません。他の CONTEXTS では、他のモデルが適用されますが、用語、概念、規則、およびユビキタス言語の方言が異なります。

問題は、作成されたさまざまな種類の注文が完全に別個の集計であるのか、それともすべてが異なる値を持つ注文集計であるのかということです。どのように作成されたかに関係なく、全体として順序を考慮する必要はありますか? 私は、さまざまな種類の注文がすべて同じ集計のインスタンスとしてモデル化された e コマース システムを構築して使用しましたが、設定が異なるだけで、言語的な問題はありませんでした。一方、ドメイン内の順序は、異なるコンテキストを保証するのに十分なほど異なる場合があります。

私は、機能的凝集の観点から BC 境界をよく考えます。注文を 2 つの BC に分離すると、それらの間に高度な結合が生じますか? もしそうなら、それはそれらを 1 つの BC に統合する必要があるという兆候かもしれません。一方、BC が対話する唯一の場所がレポート目的である場合、それらを結合する必要はありません。

于 2012-11-29T16:20:45.013 に答える
2

制限されたコンテキストを見逃したように見えます。これが発生すると、機能を既存のBCに適合させようとする傾向があります。同じことが集合ルートにも起こります。何かが不器用に見えるか、意味がない場合は、何かを見逃していないかどうかを確認してください。

あなたの例では、Shopping BC（または意味のある名前）を提案します。チェックアウトプロセスを注文BCに適合させようとしています。ショッピングBCは、すべてのデータを収集し、それを関連する部分に移動する責任があります。

選択した製品タイプによって、物理的な配送が必要かどうかが決まります。

お役に立てば幸いです。

于 2012-11-30T08:10:11.580 に答える