モジュール性の高い設計
以前、「コードの構造化」というタイトルでソフトウェアのモジュール化について述べた。
このときは初学者にもついていけるよう、「コードの分割」、「コードの結合」、「コードのグループ化」、「システムに組み上げる」という４つステップに分けてボトムアップに説明した。
理解しやすくなったとは思うが、一方でそれぞれのステップの中で説明が小さくまとまってしまい盛り込めなかったことが色々とあった。
そこで今回は改めてモジュール性について設計プロセス全体の視点から、主に前回含めることができなかった点について述べたいと思う。
前回の記事の補足資料として読んでいただければと思う。
よいモジュールの条件
モジュール性が高いソフトウェアは拡張性や再利用性に優れる。
では「モジュール性が高い」とは具体的にどのようなモジュールのことを言うのだろう？
モジュール性の５つの基準について見ていこう。
1. 組み合わせやすさ（Composability）
- 再利用可能なモジュールからソフトウェアを作るれること。
- そのためにそのモジュールが他の環境でも動作できること。
- composabilityはモジュールの再利用を促す。
- composabilityの高いモジュールは汎用ソフトウェアの開発に適している。
- composabilityの高いモジュールを再利用するということは「出来合いのもので作る」ことを優先したBottom Upアプローチなのでモジュール間の依存関係が最適化されていない傾向がある。
2. 分解しやすさ（Decomposability）
- 問題の分割のしやすさ。
- つまりは個別にモジュールの開発を進めて、後で組み合わせることで問題が解決できること。
- 作業を分割して、並行して開発できることがメリット。
- decomposabilityの高いモジュールは特定顧客向け機能の開発に適している。
- 問題解決に最適なものをTop Downに設計していくアプローチなのでモジュール間の依存関係はきれいになる
- 自然にきれいになるわけではなく、きれいに設計する必要がある
3. わかりやすさ（Understandability）
- そのモジュールを見ればそのモジュールが理解できること。
- Understandabilityは保守性を高める。
4. 連続性（Continuity）
- 仕様変更が小さければ変更するモジュールも少ないこと。
- 小さい変更がシステムに大きな影響を与えないこと。
5. 保護性（Protection）
- あるモジュールの障害が他モジュールの障害を引き起こさないこと。
よいモジュールの設計規則
上述の５つの条件を満たすための５つの設計規則を見ていこう。
1. 直接的マッピング（Direct Mapping Rule）
- 設計工程のモデルが実装と直接的にマップされるようにすること。
- 設計の変更に強くなることがメリット。
- decomposabilityとcontinuityに影響する。
2. 少ないインタフェース（Few Interface Rule）
- モジュール間の通信は最小に留めること。
- 具体的にはモジュール間で共有するメソッド、データ構造を最小限にすること。
- continuityとprotectionに影響する。
- 結合度の指標、サイズにも関連する。
3. 小さいインタフェース（Small Interface Rule）
- モジュール間でやりとりするデータ量を最小に留める。
- continuityとprotectionに影響する。
- 結合度の指標、サイズにも関連する。
4. 明示的インタフェース（Explicit Interface Rule）
- モジュール同士がやりとりしていることがそのモジュールのコード内ではっきりわかるようにする。
- 共通結合のように不健全な結合だと読み取りにくい。
- composability、discomposabilityに影響する。
- 結合度の指標、可視性にも関連する。
5. 情報隠蔽（Information Hiding Rule）
- 公開するclassやpropertyを制限する。
- privateな箇所が多いほど、外部に影響を与えることなくモジュールを変更できる。
High Cohesion / Low Coupling
上述した条件と設計規則について考える際にはモジュールの結合度について知っておくとより理解が深まるだろう。
モジュール性が高いソフトウェアは凝集度が高く、結合度が疎となる。
凝集度と結合度について過去の記事を参照して欲しい。
モジュール性の極み
ここまでコードレベルのモジュール性について述べてきた。
さらに一歩進んでアーキテクチャレベルでもモジュール化を進めたのがMicroservice Architectureだ。モジュール性の極みと言えるのではないだろうか。
ここまで行くとモジュール化によるデメリットも顕在化してきてしまう。
Webサービス開発に関わらない人間でもモジュール性の学習の締めくくりにMicroserviceについて学んがおくとよいだろう。
Microserviceについてはいずれ触れようと思う。
