はじめに
アーキテクチャにおいて「境界（Boundary）」は 責務を分離し、依存関係を制御する線 です。
しかし境界は単なる「線」ではなく、構造（Anatomy） を持っています。
本記事では、境界の構造を分解し「どのようにして機能するのか」を整理します。
境界を構成する要素
1. 契約（Contract）
- 境界を越えるときに 守るべきルール
- インターフェース、抽象クラス、API仕様 などが該当
- 契約を明示することで「越境の仕方」が標準化される
例：UserRepository インターフェース
2. データ構造（Data Transfer）
- 境界を越えるときの データの形式
- DTO（Data Transfer Object）、リクエスト/レスポンスモデル
- 内側のドメインオブジェクトと外側のデータ表現を分離
例：UserResponse ⇔ User
3. 変換（Mapping）
- 境界を越える際に、外部のデータ構造を内部に変換
- Mapper, Adapter パターンが利用される
- これにより「外部仕様の変更が内部に波及しない」
例：UserResponse.toDomain()
4. 通信手段（Interaction）
- 境界を越える際の 呼び出し方法
- 同期呼び出し（関数呼び出し、インターフェース実装）
- 非同期呼び出し（イベント、メッセージング）
例：ドメインイベント UserRegistered を発行して外側が購読
図解：境界の構造
- Interface（契約） が境界線を定義
- DTO（データ構造） がデータを越境させる器
- Mapping（変換） が外部仕様を内側に閉じ込める
境界の良い設計と悪い設計
良い境界
- 契約が明確に定義されている
- データ構造の変換があり、外部仕様が隔離されている
- テストでモック可能
悪い境界
- 内部コードが外部仕様に直結（例：SQLが直接ドメインに登場）
- DTOがなく、外部データ形式がドメインに漏れ出す
- 契約がなく、モジュール間で直接依存
まとめ
境界は「ただの線」ではなく、以下の構造を持つことで初めて機能します。
- 契約（Contract） — 越境ルール
- データ構造（DTOなど） — 越境する器
- 変換（Mapping） — 外部仕様の隔離
- 通信手段（Interaction） — 境界を越える方法
これらを意識することで、境界はシステムの 守りと拡張性 を両立する強固な基盤になります。