どんな本？
ソフトウェア設計では、モジュール間の結合をどれだけ適切に設計できるかが重要である。
本書は、この「ソフトウェアの結合設計」というテーマを深く掘り下げた一冊だ。
著者は『ドメイン駆動設計をはじめよう』の著者、Vlad Khononov氏。
前著では、ドメイン駆動設計の考え方を具体例とともに非常にわかりやすく解説している。
その書籍については、別の記事で感想をまとめている。
内容の要約
ソフトウェア設計では、結合をなるべく減らす「疎結合」が推奨される。では、結合は本当に悪なのだろうか。
本書は、結合を悪と断じない。要はバランスである。結合とはコンポーネント間の相互作用だ。システムは複数のコンポーネントの組み合わせで成り立つ。相互作用がなければシステムは動かない。だから重要なのは「結合をなくすこと」ではなく、「どの程度の結合に収めるか」という見極めだ。
では、何を物差しにバランスを取るのか。本書は三つの次元を示す。強度・距離・変動性である。結合の強度が高いものは近くに置き、低いものは遠くに置く。強度が高いのに距離が遠い関係はバランスが悪い。ただし、変動性が低いなら、必ずしも直ちに是正する必要はない。
この三つの次元に至るまでの道筋で、本書は抽象化の要点を解きほぐす。複雑性から出発し、モジュール設計、コナーセンス、結合の諸論点をたどって考察を深め、最終的に強度・距離・変動性へと収束させる。読後に残るのは、この三語のインデックスだ。その導出過程自体が、抽象化の良い手本になっている。
思考実験
本書で学んだ知識を、自分の身の回りのケースに当てはめ、思考実験として実践してみる。
プロジェクト背景
ある企業向けにWEBアプリケーションを開発している。その中の一部に、特に複雑な機能があり、これを2つのチームで分担して開発している。
全体の規模が大きいこと、また対象機能に専門的な知識が必要であることから、「専門知識が不要なチーム」と「専門知識が必要なチーム」に分けて機能を割り当てている。ここでは仮にそれぞれをAチーム、Bチームとする。
Aチーム
主にフロントエンドを担当。ユーザーに入力画面を提供し、バリデーションチェックを行ったのち、データを共有データベースのテーブルに登録する。
Bチーム
バックエンドを担当。Aチームがデータベースに書き込んだことをトリガーに、テーブルからデータを取得して複雑な処理を実行する。
問題
この2つのチームは、共有データベースを介してデータをやり取りしている。そのため、このデータベースに対する変更コストが非常に高くなっている。
たとえば、Aチーム側の都合でテーブル構造を変更しようとしても、Bチームの処理に影響が及んでしまう。これは、フロントエンド側が対象の複雑な機能とは直接関係がないにもかかわらず発生している問題である。
分析
ここでは、本書で紹介された「強度・距離・変動性」、そしてそれらを統合した「均衡度」の観点からこの状況を分析する。
強度
AチームとBチームは、テーブルを介して相互作用している。ロジックを共有していないため、これはモデル結合に該当する。
モデル結合は、結合強度の中ではそれほど強くはないが、コントラクト結合ほど弱くもない。
距離
2つの機能を別々のチームが担当しており、開発上の距離は遠い。
変動性
両チームが担当する機能は、システム全体の中でもコアサブドメインにあたる。そのため変動性は高い。
均衡度
本書で示された均衡度の式、
均衡度 = (強度 XOR 距離) OR NOT 変動性
に当てはめると、
均衡度 = (高 XOR 高) OR NOT 高 となる。
均衡度のバランスは悪く、見直しを検討する余地がある。
改善案
強度・距離・変動性の各観点から、改善策を考えてみる。
強度
現在、2チームはテーブルを介して結合しているが、Bチームが実際には参照していないカラムも含まれている。
つまり、不要な情報まで共有してしまっている。
Aチームが必要なデータだけを抽出して提供するAPIを作成し、Bチームがそれを利用するようにすれば、共有情報を最小限に絞れる。
これにより、モデル結合からコントラクト結合へと移行でき、結合強度を下げられる。
距離
AチームとBチームの役割分担を整理し、対象の複雑な機能に特化した新チームを設ける。
同じチーム内で開発を進められるようにすれば、距離を縮められる。
変動性
コアサブドメインである以上、変動性そのものを下げることは難しい。
しかし、変動性を引き上げている要因である「複雑性」を減らすことは可能である。
複雑性には、専門知識が不可欠な本質的複雑性と、連携情報の多さなどによって生じる偶有的複雑性がある。
共有モデルの利用機能やタイミングを整理し、インタフェースや機能を分割することで、偶有的複雑性を低下させられる。
振り返り
これは思考実験であるため、最終的にどのアプローチを採用するかはここでは論じない。
ただし、本書を読む前に私が考えていた改善策は、チームを統合するという「距離」に関するものだけであった。
本書を通じて、結合のバランスをとるための複数の次元から問題を考えられるようになり、追加の2つの改善策を導き出せた。
強度・距離・変動性という考え方は、ソフトウェア設計における結合バランスを考察するうえで非常に実践的なツールであると実感した。
最後に
本書を通して、ソフトウェア設計では「結合バランスの調整」がいかに重要かを学んだ。
そのバランスを構成する次元は、強度・距離・変動性の3つである。
この3次元の視点から設計を見直すことで、より均衡のとれたソフトウェア構造に近づける。
