3章モジュール性
アーキテクトや開発者は、モジュール性の概念に長い間苦しんできた。これは、1978年に出版された『Composite/Structured Design』(邦訳『ソフトウェアの複合/構造化設計』)[1]の次の引用からも明らかだ。
(ソフトウェアアーキテクチャに関する)言説の95%は、「モジュール性」の利点を称賛するために費やされている。しかし、それを実現する方法については、多少はあるにしても、ほとんど語られていない。
――Glenford J. Myers
プラットフォームによってコードの再利用メカニズムは異なる。しかし、どんなプラットフォームであっても、何らかの方法で関連するコードをモジュールにまとめられる。モジュールの概念はソフトウェアアーキテクチャの世界では一般的であるものの、その定義は曖昧だ。インターネットで検索すると何十もの定義が見つかるだろうが、それらに一貫性はないし、矛盾しているものさえある。このような問題は新しいものではない。このような問題は新しいものではない。しかし、確立された定義は存在しないものの、本書の中では一貫性を保ちたい。そこで、私たちはまずこの論争に飛び込み、独自の定義を提供したい。
モジュール性を理解し、選んだ開発プラットフォームにおけるモジュール化のための選択肢を理解することは、アーキテクトにはとても重要だ。私たちがアーキテクチャを分析する際に使うツールの多く(メトリクス、適応度関数、可視化など)は、モジュール性や関連する概念に依存している。モジュール性とは組織化の原則だ。もし、アーキテクトが要素同士の繋がりに注意を払わずにシステムを設計したとすると、数えきれない困難をもたらすシステムが出来上がってしまうことになる。物理学に例えるなら、ソフトウェアシステムは複雑系であり、エントロピーが増大する(無秩序に向かう)傾向がある。物理システムの秩序を維持するには、エネルギーを加えなければならない。ソフトウェアシステムも同じことが言える。アーキテクトは、偶然に身を委ねるのではなく、構造を良い状態に保つために常にエネルギーを費やし続けなくてはならない。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access