ソフトウェア設計の結合とバランス_1章

Transcript

1. ソフトウェア設計の 結合とバランス 持続可能な成長を支えるモジュール化の原則 1章 結合とシステム設計
2. はじめに • • • ソフトウェア設計に関する書籍で結合の説明に割かれるのは、通常数ページほど 『結合（依存）は悪』という言葉をどこでも耳にする。 『マイクロサービスは疎結合を実現するためのアーキテクチャである。』 ↓ 2014年ごろ、猫も杓子もマイクロサービスについて語っていたが、同時は誰もマイクロ サービスが実際に何なのか定義出来ていなかった。 『Structured Design』(邦訳『ソフトウェアの構造化設計手法』)の6章に、そのヒントが書 かれていた。その章のタイトルは・・・『結合』だった。 2
3. イントロダクション 一流のスイス時計を想像してみてほしい。スイス公認のクロノメーター検査協会は、 15日間の試験期間中、平均して遅れが4秒以内、進みが6秒以内でなければなら ないと定められている。加えて、現代の時計には、クロノグラフ、日付表示 etc… と いった複雑な機構も組み込まれている。これらは全て、何百もの微小な部品によっ て実現されている。 部品間の相互作用の精度は最も重要。例えば、 • • 潤滑が不十分なために接続がきつすぎると、過度な摩擦によって時計の動きが遅 くなってしまう。 逆に部品が潤滑されすぎていると、歯車やバネが自由に動きすぎて時計の動きが 速くなってしまう。 3
4. イントロダクション 結合はなぜ重要なのか？ 高級機械式時計は、単に時間を刻む機械ではない。時間の経過とともに大きな価値を 蓄積する有形資産。 ↓ これは、成功したソフトウェアシステムにも当てはまる。 ソフトウェアシステムの価値とは、現在備えている機能だけではなく、進化や成長、将来 の要求にも応える能力も反映したもの。本書で学ぶように、時の試練に耐えるシステム を構築するには、コンポーネント間の相互作用を効率的に設計することが不可欠。 なぜ、ある設計の決定が複雑性をもたらし、他の決定がシステムのモジュール性を高め るのかを探る。 4
5. 結合とは何か 結合は、世界中のソフトウェアエンジニアの宿敵となるずっと前から存在していた。結合 （coupling）はラテン語の”copulare”に由来する。 copulare = ともに固定する、物事を結びつける(connected) 結合は、接合されたコンポーネント間の関係を示している。もしコンポーネントが結合さ れているなら、それらは何らかの形で影響を及ぼし合う可能性がある。 5
6. 結合の強度 ソフトウェア設計では、結合度が高ければ高いほど、結合されたコンポーネントを一緒に 変更する頻度が高くなる。 しかし、なぜ一緒に変更しなければならないのだろうか。 その理由は、 1. 2. ライフサイクルの共有 知識の共有 にある。 6
7. 結合の強度（ライフサイクルの共有） 複数のコンポーネントを一緒にする必要がある単純な理由は、それらのライフサイクル が結合されている点にある。 同じモノリシックアプリケーション内に共存しているモジュールは、一緒にテスト・デプロイ ・メンテナンスをする必要がある。 ↓ 一方、モジュールを異なるサービスに分離すると、 それらのライフサイクルの結合度は低くなり、 それぞれのモジュールをより独立して開発・ メンテナンスできるようになる。 7
8. 結合の強度（知識の共有） 結合されたコンポーネントが強調して動作するには、それらの間で知識を共有する必要 がある。その形は、統合インターフェイス、機能要件、対応するモジュールの実装詳細に まで及ぶ。 共有されている知識の一部を変更した場合には、接続されたモジュールも同様に変更さ れなければならない。 そのため、境界を超えてコンポーネント間で共有している知識が多ければ多いほ ど、より多くの連鎖的な変更が発生する。 8
9. 結合の強度（知識の共有） 共有する知識の量が異なる3つの設計 9
10. 結合の強度（知識の共有） まとめると、 • • • 設計Aは、使用している具体的なデータベース（MySQL）という最も多くの知識を共 有している。 設計Bは、知識をデータベースの種類に縮小している。 設計Cはさらにカプセル化し、CustomerServiceモジュールが機能を実装するため に必要な最小限の知識のみを公開している。 『知識』に対する変更は、影響を受けるコンポーネント全体に伝播させる必要がある。（さ らに、コンポーネントは、明示的に定められたり共有されたりしていない知識であっても、 システムの他の部分について暗黙の前提を持つ可能性がある。(システムが特定の バージョンのやOS、特定のハードに依存するなど。)） そのため、共有される知識が多いほど、変更する理由も多く共有されることになる。 10
11. 知識の流れ 2つの結合されたコンポーネントを考えてみる。 下の例では、Distributionコンポーネントは、CRMコンポーネントを参照（に依存）してい る。この時、DistributionコンポーネントはCRMコンポーネントの統合インターフェース、 機能、運用についての詳細を認識している必要がある。 • • Distributionコンポーネントは、統合インターフェイスを通じて、CRMモジュールから これらの知識を共有されている。 結果として、知識の流れは、依存関係とは逆の方向に発生している。（これらの知 識の流れに関して、上流/下流と表現する。） 11
12. システム 盲目的に、相互依存を導入すれば良い設計になるというわけではないが、システムの目 的を拡張したい場合は、コンポーネントを変更する必要がある。さらにコンポーネントを 変更する際には、相互作用（統合の仕方、通信の仕方）の変更が必要になる。 12
13. まとめ システムは目的とコンポーネントから構成される。コンポーネントがシステムの目的を達 成するには、コンポーネント間の相互作用（結合）が必要。 結合は、各コンポーネントが知識やライフサイクル、あるいはその両方を共有しなけれ ばいけないことから生じる 13
14. 演習問題 14