最近この本を読んでみたのでアウトプットとしてブログを書きます～ tatsu-zine.com

読んだきっかけ

最近は内部品質として設計やアーキテクチャの知見に興味あるため、読んでみました。
具体的には、プロダクトが成長するにつれて認知負荷が高まり、それによってバグや仕様漏れ、生産性の低下につながっているのではないか、とここ最近気付きました。こうした課題に対処する手段として、認知負荷を抑えるような設計やアーキテクチャの工夫が重要であり、その部分に関わっていきたい気持ちがどんどん強くなっているためです。

特に学びになった点/面白かった点

アーキテクチャの目的、アーキテクトの目的、ソフトウェア開発者の目的を知れた点

アーキテクチャの目的
- 求められるシステムを構築・保守するために必要な人材を最小限に抑えること。
- システムのライフサイクルをサポートすることで。優れたアーキテクチャがあれば、システムを容易に理解・開発・保守・デプロイできる。最終的な目的は、システムのライフタイムコストを最小限に抑え、プログラマの生産性を最大にすること。
それらを容易にするための戦略は、できるだけ長い期間、できるだけ多く選択肢を残すこと。
アイゼンハワーマトリクスに当てはめると、アーキテクチャは"重要"、振る舞い"緊急"に該当する。
- ソフトウェア開発者は、アーキテクチャの重要性を主張する責任がある。保護すべきソフトウェアに対する責任がある。
- とくにアーキテクトであれば特に重要。アーキテクトは、機能を簡単に開発・変更・拡張できるアーキテクチャの構築を求められる

目的について、特にアーキテクチャは短期的な視点だけでなく、長期的な視点を持って全体の構築を考えなければならない、と理解しました。

クリーンアーキテクチャの図の理解

クリーンアーキテクチャと言えば、4つの同心円の図が有名ですよね。

エンティテイはビジネスであり、それ以外の何者でもない。外部で何か変化が起きても、それが変化する可能性は低い。(p.191)

ユースケースとは、自動化されたシステムを使用する方法を記述したものである

4つの円について、私の理解としてはクリーンアーキテクチャは動かないものに中心に据えてそこに依存すべき という考え方と理解しました。その境界線を境界を考えていくことの重要性もこの本では解かれていたと思います（現時点で、境界に関する詳細をあまり理解できてませんが...）

フレームワークとの結婚するな

フレームワークがあくまで詳細であること、そして、いかなる状況においても、フレームワーク作者から我々に何らかの約束をすることはなく、これは一方的な結婚であること。つまり、すべてのリスクと負担を背負うのは我々であり、フレームワークの作者は何ひとつ背負うことはない。
「フレームワークなんかと結婚するな！」そのためには、フレームワークとは一定の距離を保つこと。フレームワークは、アーキテクチャの円の外側にあるものとして扱い、円の内側に組み込んではいけない。

「フレームワークなんかと結婚するな！」という言葉が強くて面白かったこと、そして適切なフレームワークへの付き合い方を学ぶことができ、依存しすぎないようにしようと思いました。

まだまだ理解ができていない点

読み終わったのですが、以下の内容はあまりまだ理解できていません。 - SOLIDの原則の特にOLIの詳細の理解 - コンポーネントの原則の詳細の理解 - 境界線の付け方

おわりに

今回アーキテクチャに関する技術書をで初めて読んでみました。雰囲気はつかめたものの、詳細を理解できていない部分も多かったです。
この本を読んだだけではまだ完全に理解するものではなく、実務経験や他の技術書の知識が必要なのだろうと思っていて、将来またこの本に戻ってくると理解がより深まるのかなと思いました。 DDDにも絡みそうな感じがするので、その辺も今後学んでいきたいです。