境界
このドキュメントの目的
**境界（Boundary）**とは何か、なぜ境界を引く必要があるのか、どこに引くべきかを理解することが目標です。
目次
境界とは何か
境界の定義
┌──────────────── ─────────────────────────────┐
│ 境界とは │
├─────────────────────────────────────────────┤
│ │
│ 「変更の理由が異なるものを分ける線」 │
│ │
│ 境界で分けられた両側は: │
│ ├── 別々の理由で変更される │
│ ├── 別々のタイミングで変更される │
│ └── 別々のチームが担当できる │
│ │
└─────────────────────────────────────────────┘
ソフトウェアにおける境界
┌─────────────────────────────────────────────┐
│ ソフトウェアの境界の例 │
├─────────────────────────────────────────────┤
│ │
│ ビジネス ロジック | インフラ │
│ ↑ │
│ 境界 │
│ │
│ 変更の理由: │
│ ビジネスロジック: 業務要件の変更 │
│ インフラ: 技術的な理由（性能、コスト等） │
│ │
└─────────────────────────────────────────────┘
なぜ境界を引くのか
変更の影響を限定する
┌─────────────────────────────────────────────┐
│ 境界がない場合 │
├─────────────────────────────────────────────┤
│ │
│ 全てが混在: │
│ ビジネスロジック + DB処理 + UI処理 │
│ │
│ DBを変更すると: │
│ → ビジネスロジックも確認が必要 │
│ → UIも確認が必要 │
│ → 全体のテストが必要 │
│ │
│ 小さな変更が大きな影響を持つ │
│ │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 境界がある場合 │
├─────────────────────────────────────────────┤
│ │
│ 明確に分離: │
│ [ビジネス] | [インフラ] | [UI] │
│ │
│ DBを変更すると: │
│ → インフラ層のみ確認 │
│ → 境界のインターフェースは維持 │
│ → 他の層は影響なし │
│ │
│ 変更の影響が限定される │
│ │
└─────────────────────────────────────────────┘
独立した開発を可能にする
┌─────────────────────────────────────────────┐
│ 境界による独立性 │
├─────────────────────────────────────────────┤
│ │
│ 境界で分けると: │
│ │
│ ├── 別々に開発できる │
│ │ ビジネスロジックの開発中でも │
│ │ DBの実装は後から決められる │
│ │ │
│ ├── 別々にテストできる │
│ │ ビジネスロジックはDBなしでテスト可能 │
│ │ │
│ └── 別々にデプロイできる │
│ （マイクロサービスなら） │
│ │
└─────────────────────────────────────────────┘
選択を遅らせられる
┌─────────────────────────────────────────────┐
│ 決定の先送り │
├─────────────────────────────────────────────┤
│ │
│ 境界があると: │
│ │
│ 「DBは何を使うか」 │
│ → 後で決められる │
│ → ビジネスロジックの開発は先に進められる │
│ │
│ 「UIフレームワークは何にするか」 │
│ → 後で決められる │
│ → コア機能の開発は先に進められる │
│ │
│ 重要な決定を十分な情報が集まってから下せる │
│ │
└─────────────────────────────────────────────┘
どこに境界を引くべきか
基本的な考え方
┌─────────────────────────────────────────────┐
│ 境界を引く基準 │
├─────────────────────────────────────────────┤
│ │
│ 「変更の理由が異なる」ところに引く │
│ │
│ 質問: │
│ ├── これとあれは同じ理由で変わるか？ │
│ ├── 別の人/チームが担当すべきか？ │
│ └── 片方を変えずにもう片方を変えたいか？ │
│ │
│ 答えがNoなら境界を検討する │
│ │
└─────────────────────────────────────────────┘
典型的な境界線
┌─────────────────────────────────────────────┐
│ よく引かれる境界 │
├─────────────────────────────────────────────┤
│ │
│ 1. ビジネスロジック | データベース │
│ 理由: DBは技術的選択、ロジックは業務要件 │
│ │
│ 2. ビジネスロジック | UI │
│ 理由: UIは見た目、ロジックは業務ルール │
│ │
│ 3. ビジネスロジック | 外部API │
│ 理由: 外部の変更を自分で制御できない │
│ │
│ 4. ドメインA | ドメインB │
│ 理由: 異なるビジネス領域 │
│ │
└─────────────────────────────────────────────┘
境界の実現方法
┌─────────────────────────────────────────────┐
│ 境界をコードで表現する │
├─────────────────────────────────────────────┤
│ │
│ インターフェース: │
│ └── 境界を越える通信はインターフェース経由 │
│ │
│ パッケージ/モジュール: │
│ └── 物理的にコードを分離 │
│ │
│ アクセス制御: │
│ └── 境界を越えた不正なアクセスを防ぐ │
│ │
└─────────────────────────────────────────────┘
境界の引きすぎ・引かなすぎ
引きすぎの問題
┌─────────────────────────────────────────────┐
│ 境界の引きすぎ │
├─────────────────────────────────────────────┤
│ │
│ 症状: │
│ ├── 小さな変更でも複数ファイルを修正 │
│ ├── インターフェースだらけ │
│ ├── どこに何があるかわからない │
│ └── 「シンプルなこと」が複雑になる │
│ │
│ 原因: │
│ └── 将来の変更を過度に予測している │
│ 実際には起きない変更のために複雑化 │
│ │
└─────────────────────────────────────────────┘
引かなすぎの問題
┌─────────────────────────────────────────────┐
│ 境界の引かなすぎ │
├─────────────────────────────────────────────┤
│ │
│ 症状: │
│ ├── 小さな変更が全体に波及する │
│ ├── テストにDBや外部サービスが必要 │
│ ├── フレームワークを変えられない │
│ └── 一部だけ変更することが困難 │
│ │
│ 原因: │
│ └── 異なる責務が混在している │
│ 分けるべきものが分かれていない │
│ │
└─────────────────────────────────────────────┘
バランスの取り方
┌─────────────────────────────────────────────┐
│ 適切な境界の判断 │
├─────────────────────────────────────────────┤
│ │
│ 今ある痛み: │
│ ├── テストが書きにくい → 境界が必要 │
│ ├── 変更の影響が大きい → 境界が必要 │
│ └── コードが複雑すぎる → 境界の見直し │
│ │
│ 将来の予測: │
│ ├── 確実に変わる → 境界を引く │
│ ├── 変わるかもしれない → 様子を見る │
│ └── 変わらなそう → 境界は不要 │
│ │
│ 「今」の痛みを優先し、「将来」は控えめに │
│ │
└─────────────────────────────────────────────┘
まとめ
境界とは
「変更の理由が異なるものを分ける線」
境界で分けることで:
├── 変更の影響を限定できる
├── 独立して開発・テストできる
└── 技術選択を遅らせられる
どこに引くか
基準: 「変更の理由が異なる」か
典型的な境界:
├── ビジネスロジック | DB
├── ビジネスロジック | UI
├── ビジネスロジック | 外部API
└── ドメインA | ドメインB
バランス
引きすぎ: 過度な複雑さ
引かなすぎ: 変更の困難さ
「今ある痛み」を基準に判断する
次のステップ
- アーキテクチャの変種 でヘキサゴナル/オニオンとの関係を学ぶ