状況に応じた境界位置
「非常時だからモノリスが良い」
「平常時だから分散がいい」という単純な二元論ではなく、
「どの境界が、どの状況で、どのように振る舞うべきか」
を個別の置かれたシーンごとに分析し、境界ごとに最適な結合度を選択するというアプローチが大切です。
これはシステム内のあらゆる「コンテキスト境界の位置」を、以下の2つの軸で大きく分類し、評価するフレームワークと言えます。
・平常時の望ましい結合度（効率性や開発速度のため）
・非常時の望ましい結合度（回復力や対応速度のため）
「平常時」と「非常時」の結合度マトリクス
この判断基準は、以下の4象限マトリクスで整理できます。
アーキテクトは、システム内のあらゆる境界がこの中のどこに位置するかを評価し、
設計案を決定すべきです。
| 非常時：疎結合が望ましい （障害の拡大を防ぐ、独立して復旧させる） |
非常時：密結合が望ましい （一体となって原因究明・復旧にあたる） |
|
|---|---|---|
| 平常時：疎結合が望ましい （自律的に開発・デプロイできる） |
✅ 第1象限：問答無用で分割 常に疎結合であるべき理想的な境界。 |
🧠 第2象限：統合を維持 平常時のデータに惑わされず、非常時のためにあえて統合を維持すべき境界。 |
| 平常時：密結合が望ましい （トランザクションの一貫性、開発の利便性） |
⚖️ 第3象限：最も困難なトレードオフ 平常時の利便性と、非常時のリスクが衝突する境界。 |
第4象限：分割する理由がない 常に密結合であるべきドメインの核。 |
✅ 第1象限：問答無用で分割（疎/疎）
私の主張
「平時でも非常時でもどの状況でも疎結合であるような境界は、問答無用で境界を設ける」
具体例
コアな決済システムと、社内向けの分析・BI基盤。決済システムで障害が起きても、
BI基盤チームと密に連携する必要はほとんどありません。
むしろ、境界を設けておくことで、決済システムの障害がBI基盤に波及するのを防げます（障害の隔離）。
決定
ここは迷うことなく、組織的にも技術的にも明確に分割すべきです。
私ならネットワークセグメント自体も分けて配置します。
たとえ、それでネットワークインフラの運用コストが増えたとしても。
レイテンシーが同じネットワークセグメントにある時よりも多くても。
たとえば、ネットワークセグメントを分けることはできないとしても、
せめて最低限、非同期な関係にはしておきましょう。
🧠 第2象限：統合を維持（疎/密）
私の主張
「平時でのコンテキスト境界の場所が、非常時では密に繋がらないといけないという境界位置に対しては、非常時のレジリエンス能力を優先し、境界で区切らないままにしておく」
具体例
コンテナ基盤（K8s）チームと、その上で動くメッセージング基盤（Kafka）チーム。
平常時はそれぞれ独立して作業できますが、大規模なインフラ障害時には一体となって動く必要があります。
決定
平常時のコミュニケーションデータだけを見てチームを分割すると、
非常時の対応能力が著しく低下します。
この場合、あえて組織的な統合を維持し、合同訓練などで連携能力を保つのが賢明です。
⚖️ 第3象限：最も困難なトレードオフ（密/疎）
ここがもっとも頭を悩ませる領域です。
・平時での利便性を捨ててでも、非常時の回復性を取るのか？
・それとも平時の利便性を取り、非常時の回復力を犠牲にするのか？
私の主張
非常時で疎結合にしておいた方が良い境界位置というのは当然あります。
平時では蜜結合な方が望ましい場合には、トレードオフになるとわかっていますが
そこはあえて仮想的に分割しておく 方が良いと考えます。
具体例
アプリケーションとインフラのデプロイを一つの巨大なCI/CDパイプラインで管理している状況。
平常時は、一度のデプロイで全てが完了するため密結合が便利です。
しかし、インフラ部分の変更にバグがありパイプラインが停止した場合、それとは無関係なアプリケーションの緊急ホットフィックスすらデプロイできなくなります。
このような非常時には、
パイプラインが疎結合であってほしかった
と強く思うことになります。
決定
ここが最も難しいトレードオフです。
非常時の回復力を重視するならば、平常時の利便性を多少犠牲にしてでも、長期的なリファクタリングの対象として分割を目指すべき領域と言えます。
第4象限：分割する理由がない（密/密）
絶対に分割しない！！
具体例
銀行の勘定系システムにおける、取引処理エンジンと残高更新モジュール。
これらはビジネスロジック上、トランザクションとして常に一体でなければならず、
障害発生時も不可分な単位として扱われます。
決定
平常時も非常時も密結合が求められるため、分割を検討する必要はありません。
結論
1元的に単純なルールに頼るのではなく、システム内の各境界の特性を「平常時」と
「非常時」という、ざっくり2つのコンテキストで分類し、それぞれで評価し、リスクと効率のトレードオフを考慮して最適なアーキテクチャを選択する。
これは、まさにレジリエントなシステムを設計するための私なりの実践方法です。