ソフトウェアアーキテクチャの古典を読んでいく

システムはコンポーネントの相互作用で実現される。そしてそのコンポーネントもまたシステムである。

オブジェクト指向の原点とかないとか。そんな感じの個展ってぽいので読んでおこうと思う。

アーキテクチャの良し悪しはどう評価するのか、モジュール分割の良し悪しはどう評価するのかが気になってる自分にGood

なお、LLMに翻訳させてるので、以下引用文は全て日本語になる。

モジュールの利点

1. 別々のグループが各モジュールで作業をし、独立して開発できるので開発時間を短縮できる

2. 他モジュールを変更することなく、独立して作り直したりできる

3. 各モジュールを独立して理解できるため、システムの理解容易性が上がる

そのモジュールを切ったことがどう評価すれば良いのか

ただし....以下とのこと

この機能は大規模なコードの生産にとって極めて価値があるが、問題のあるシステムの例として最もよく使用されるシステムは、高度にモジュール化されたプログラムであり、上述の技術を利用している。

フローチャートに従って、処理別にモジュール化するな。情報隠蔽を意識して、変更される箇所を隠すようにモジュール化しよう

処理別に分けてしまうと、同じ知識に依存するモジュールが沢山生まれる。

ということは、その知識が変更されたら依存するモジュールは全て変更対象になる。

もしその知識が、1つのモジュールのみが気にするだけで良いように、モジュール分解をできた場合、変更点は1つになって楽だよねって話。

具体例が必要かな？

いや、ていうか、システム運用をする中で、上記のモジュール分解による利点を得られているのなら、それは良い分解なのかもしれない。後からわかる的な。