境界づけられたコンテキスト - 言葉の意味が変わる場所に境界を引く

2026.06.14

公式ドキュメント
仕組み解説設計DDDアーキテクチャ

境界づけられたコンテキストとは、ある言葉やモデルが一貫した意味を持つ範囲のことです。

一言でいうと

同じ言葉が違う意味で使われる場所には、設計上の境界を引く必要があります。

「顧客」という言葉でも、営業では見込み客、請求では支払い相手、サポートでは問い合わせ元を指すことがあります。これらを1つの巨大なCustomerモデルに押し込むと、意味が混ざります。

なぜ境界が必要か

境界がないと、次の問題が起きます。

  • 1つのモデルに無関係なフィールドが増える
  • ある部署の仕様変更が別部署の機能を壊す
  • 同じ言葉なのに会話が噛み合わない
  • マイクロサービスの境界が曖昧になる
  • DB共有によって変更できなくなる

境界づけられたコンテキストは、こうした混乱を避けるための設計単位です。

例: ECサイトの「注文」

コンテキスト注文の意味
販売顧客が購入した商品と金額
倉庫出荷すべき品目と数量
請求請求対象と支払い状態
サポート問い合わせ対応の履歴

同じ「注文」でも、必要な情報とルールが違います。すべてを1つのモデルにすると、どの文脈でも使いにくくなります。

コンテキスト内とコンテキスト間

範囲目的設計の焦点
コンテキスト内モデルの一貫性を守るエンティティ、値オブジェクト、集約
コンテキスト間意味の変換を管理するAPI、イベント、Anti-Corruption Layer

境界の内側では、言葉の意味を一貫させます。境界を越えるときは、別の言葉や形式へ変換します。

コンテキストマップ

コンテキストマップは、複数のコンテキストの関係を図として整理するものです。

関係意味
Customer/Supplier一方がAPIや仕様を提供する
Conformist相手のモデルに合わせる
Anti-Corruption Layer変換層を挟んで汚染を防ぐ
Shared Kernel一部のモデルを共有する
Separate Ways連携せず独立させる

すべての境界をAPI化すればよいわけではありません。関係性に応じて連携方法を選びます。

マイクロサービスとの関係

境界づけられたコンテキストは、マイクロサービスの候補になります。ただし、コンテキストを見つけたからといって、必ずサービス分割する必要はありません。

状況選択
チームもデプロイも分けたいサービス分割を検討
まだ小さく変更も少ないモジュラーモノリスでよい
DB共有が強すぎる先に境界整理
言葉の意味が混ざっているコンテキスト分離を優先

サービス分割より先に、モデルと言葉の境界を整理することが重要です。

よくある誤解

DBテーブル単位で境界を決める

DB構造は結果であって、境界の出発点ではありません。業務の言葉、変更理由、チームの責任範囲から考えます。

境界を細かくすればよい

細かすぎる境界は連携コストを増やします。モデルの意味が一貫していて、同じ理由で変更される範囲をまとめます。

共通モデルを作れば解決する

全社共通の巨大モデルは、多くの場合うまくいきません。コンテキストごとの意味を保ち、必要なところだけ変換します。

導入チェックリスト

  • 同じ単語が複数の意味で使われていないか
  • 仕様変更の理由が違う機能を同じモデルに入れていないか
  • チームの責任範囲とモデルの境界が極端にずれていないか
  • 境界を越えるデータ変換を明示しているか
  • DB共有が境界を壊していないか

まとめ

境界づけられたコンテキストは、システム分割の前に言葉の意味を分割する考え方です。

境界は技術都合ではなく、業務上の意味と変更理由に合わせて引きます。

参考リソース

関連記事

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR