境界づけられたコンテキスト

境界づけられたコンテキストは、ドメイン駆動設計（DDD）の中心的なパターンです。これは、大規模なモデルとチームへの対処に関するDDDの戦略的設計セクションの中核です。DDDは、大規模なモデルを異なる境界づけられたコンテキストに分割し、それらの相互関係を明確にすることで、大規模なモデルを扱います。

DDDは、基盤となるドメインのモデルに基づいてソフトウェアを設計することです。モデルは、ソフトウェア開発者とドメインエキスパート間のコミュニケーションを支援するためのユビキタス言語として機能します。また、ソフトウェア自体の設計（オブジェクトまたは関数への分解方法）の概念的な基盤としても機能します。効果的なモデルにするには、モデルを統一する必要があります。つまり、内部的に矛盾がないようにする必要があります。

より大きなドメインをモデル化しようとすると、単一の統一モデルを構築することが次第に難しくなります。大規模な組織のさまざまな部署の人々は、微妙に異なる語彙を使用します。モデリングの精度はこれにすぐに直面し、多くの場合、混乱を招きます。通常、この混乱はドメインの中心概念に焦点を当てています。私のキャリアの初期には、電力会社で働いていました。ここでは、「メーター」という言葉は、組織のさまざまな部分で微妙に異なる意味を持っていました。グリッドと場所、グリッドと顧客、物理的なメーター自体（故障した場合は交換可能）の接続です。これらの微妙な多義語は、会話ではスムーズに処理できますが、コンピューターの正確な世界では処理できません。「顧客」や「製品」などの多義語で、この混乱が繰り返し発生するのを見てきました。

当時は、ビジネス全体の統一モデルを構築するようにアドバイスされていましたが、DDDは、「大規模システムのドメインモデルの完全な統一は実現不可能または費用対効果が高くない」ことを学びました[1]。そのため、DDDは、大規模なシステムを境界づけられたコンテキストに分割します。それぞれのコンテキストは、統一されたモデルを持つことができます。これは、本質的に複数の標準モデルを構築する方法です。

境界づけられたコンテキストは、無関係の概念（カスタマーサポートコンテキストにのみ存在するサポートチケットなど）と、共通の概念（製品や顧客など）を共有します。異なるコンテキストでは、共通概念のモデルが完全に異なり、統合のためにこれらの多義的な概念間をマッピングするメカニズムがあります。いくつかのDDDパターンは、コンテキスト間の代替関係を探ります。

さまざまな要因がコンテキスト間の境界線を引きます。通常、支配的なものは人間の文化です。モデルはユビキタス言語として機能するため、言語が変化すると異なるモデルが必要になります。また、単一のアプリケーションのメモリ内モデルとリレーショナルデータベースモデルの分離など、同じドメインコンテキスト内に複数のコンテキストがあります。この境界は、モデルを表すさまざまな方法によって設定されます。

DDDの戦略的設計では、境界づけられたコンテキスト間のさまざまな関係について説明しています。通常、コンテキストマップを使用してこれらを描くことは価値があります。