No content

梶川 琢馬 𝕏 @kajitack 株式会社 TechBowl VPoT TechTrain の開発やメンターを担当してます！ 技術書ライブラリーのサポーター 

No content

ソフトウェア設計の結合バランス Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems の翻訳 IDDDの著者(Vaughn Vernon)が編集している シリーズの 1 冊 1冊をまるまる「結合」に割いた本 4/15 

著者 Vlad Khononov ヴラド・ホノノフ 前著『Learning Domain-Driven Design』 （邦訳『ドメイン駆動設計をはじめよう』） 同じ著者だと、気付かずに買って勝手に感動した 5/15 

結合は悪? 完全に結合のないシステムは機能しない 結合はシステムをまとめ上げる不可欠な接着剤 目的を実現するための良い結合を目指す 6/15 

Part I 結合 結合の定義、複雑性（クネビン・相互作用）、モジュール性との関係を整理する 第1章 結合とシステム設計 第2章 結合と複雑性：クネビン 第3章 結合と複雑性：相互作用 第4章 結合とモジュール性 結合は「欠陥」ではなく、 システムを舵取りする設計ツール 完全に結合のないシステムは機能しない —— 結合は不可欠な接着剤 複雑性の正体は「相互作用」 クネビンで状況を識別する モジュール性か複雑性か —— 結合の設計が方向を決める 7/15 

Part II 次元 古典モデル（モジュール結合・コナーセンス）を統合し、統合強度・距離・変動性の 3 次元を定義する 第5章 構造化設計におけるモジュール結合 第6章 コナーセンス 第7章 統合強度 第8章 距離 第9章 変動性 結合がシステムに与える影響を 3 つの次元で評価する 強度 — どれだけ深く結びつくか （統合強度 4 レベル） 空間（距離）— どれだけ離れているか （コード・チーム・同期性） 時間（変動性）— どれだけ変わるか （DDD サブドメインで評価） 8/15 

Part III バランス 均衡結合モデルを定義し、再均衡化・フラクタル性・実践ケーススタディまで踏み込む 第10章 結合の均衡化 第11章 結合の再均衡化 第12章 ソフトウェア設計のフラクタル幾何学的性質 第13章 均衡結合の実践 第14章 結論 第15章 エピローグ 3 次元を組み合わせて、結合を 実践的な「設計ツール」へ昇華する 均衡結合モデル — 強度・距離・変動性 の組み合わせを論理式で評価 再均衡化 — 戦略的変更に追従して 設計を磨き続ける フラクタルな原則 — 共有知識が多いほど 距離を近く、少ないほど遠ざける 9/15 

例：非同期処理における結合 1. 非同期通信は「統合強度」を下げるわけではない 通信方式が同期的か非同期的かは、モジュール境界を越えて共有される「知識」には影響を 与えず、統合強度の強さはメッセージの内容や業務要件による 2. 「実行時結合」を下げ、「距離」を広げる 非同期通信の最大の利点は、「実行時結合（運用上の依存関係）」を低く抑えられる。 3. 距離が広がることで「変更コスト」が増加する 距離が広がることは独立性を高める一方で、もし強い統合強度（たとえばモデル結合や 機能結合）を持ったまま非同期通信を行っていると、変更時のコスト（調整の労力）が 同期通信よりもかえって高くなる。 10/15 

PHPerKaigi 2026で時間的結合を深掘り https://speakerdeck.com/kajitack/messaging-temporal-coupling 11/15 

結合の評価指標 時代 モデル名 評価指標 1960年代 モジュール結合 （6段階） 内容結合、共通結合、外部結合、 制御結合、スタンプ結合、データ結合 1990年代 コナーセンス （共生的関係） 静的（名前、型、意味、位置、アルゴリズム） 動的（実行、タイミング、値、アイデンティティ） 2024年 統合強度・距離・変動性 （3次元） 統合強度：侵入/機能/モデル/コントラクト結合 距離：コード配置/チーム/同期性 変動性：コア/支援/汎用サブドメイン 12/15 

この本の語彙を どう活かすか？ 13/15 

チームで暗黙知を言語化する 設計レビューで「もっと疎結合に」で止まっていたのが、 「統合強度が高い」「距離の結合だ」と踏み込める とはいえ、個別のレビューではそこまで使わなさそう(感覚) チームにはAIも含む — レビュースキルに組み込むことで計測 レビュースキルをチームで育てていく (まだ途中) 14/15 

「要はバランス」から次のステップへ 一般論ではなく、プロジェクト固有の文脈で判断する 変動性（変更頻度）で優先順位と妥協点を決める バランスを取る＝大域的複雑性（距離を離してまたぐコスト）か、局所的複雑性（距離を 近づけて認知負荷が集中）か 開発者の抽象化レベルによって認識が変わる。両方の複雑性を管理する 「強度が低いなら距離を離し、強度が高いなら距離を近づける」 15/15