- ソフトウェア開発の核心的な難題の多くは、コードの内部ではなく、コードとコード、システムとシステムが 出会う境界（Boundary） で発生するという主張
- 境界 = 異なる関心事・責任・文脈が交わる地点
- 関数分離、モジュール化、マイクロサービスなど、開発のほぼすべての行為は境界を作る行為
- アイロニー: 複雑性を扱うために境界を作るが、境界そのものが新たな複雑性の源泉になる
コードで発生する境界
- 呼び出し元-呼び出し先の境界: null を返すのか例外を投げるのかといった契約の曖昧さ
- インターフェースの境界: 抽象化漏れの法則 - 隠された複雑性はいつか境界を突き破って現れる
- 依存関係の境界: 外部 API・ライブラリは予告なく変わることがある
- 変換の境界: オブジェクト関係インピーダンスミスマッチのように、境界を越えるたびに情報が歪んだり失われたりする
- 信頼境界: 検証済みデータと未検証データの境界 → 署名のない Webhook の受信などセキュリティ脆弱性につながる
- 設計-実装の境界: 要件 → 設計 → 実装 → 運用の各段階で情報損失が蓄積する
物理的な境界
- 順序の境界: 非同期の区間のあいだに状態が変わる可能性があり、分散システムではさらに深刻
- 規模の境界: 閾値を超えると量的変化ではなく質的変化が起こる
- 環境の境界: 「自分のマシンでは動くのに」という事態が起きる
- インフラの境界: サービスを分離すると原子性を保証できない
人のあいだで発生する境界
- 組織の境界: コンウェイの法則 - 組織構造がシステム構造を決める。チーム再編時にはコードと組織の境界がずれる
- コミュニケーションの境界: 伝言ゲームのように、要件が伝達されるたびに意図が変形し、暗黙知はそもそも伝わらない
- ユーザー-開発者の境界: 開発者が安全のために作った境界が、ユーザーには煩わしい障壁になる
境界を制御する方法
- 隠れた境界を認識せよ: 2つのサービスが同じ DB テーブルを共有しているように、コード上では見えない結合に注目する
- パターンは答えではない: パターンは「特定条件で効果的な解法」にすぎず、盲目的な適用は禁物
- 境界の前で投げるべき3つの問い:
- この境界を越えるのは何か?
- この境界が壊れたら何が起こるか?
- この境界は誰が管理するのか?
- 境界を引かないことも選択肢: モノリスを維持する、早まった分離を避けるなど
- 境界は進化する: 分離しては統合し、統合しては再び分けることを繰り返す → 意識的かつ定期的な再検討が必要
まだコメントはありません。