iCARE の若手エンジニアにおすすめの本を紹介するシリーズ その2. Clean Architecture 達人に学ぶソフトウェアの構造と設計
 |
ドワンゴ
発売日 : 2018-08-01
|
アーキテクチャというのは幽霊のようなものでみんなが話すけど見ることはできません。そして、ソフトウェアの基礎の基礎であるにも関わらず、アーキテクチャを考えられるエンジニアというのは驚くほどに少ないです
ということで、二冊目はみんな大好きアンクル・ボブのクリーンアーキテクチャです
どんな本
この本を読む前にまず、クリーンアーキテクチャといえばのあの有名の図は忘れましょう。この本の紹介記事はたくさんありますが、例の図を使って紹介しているものはすべて間違っています（断言
誤解を恐れずにいうとこれは SOLID 原則の解説本です。ソフトウェアの歴史から SOLID 原則の成り立ちを、ソフトウェアの構造とそれぞれの部分でみられるパターンから SOLID 原則の応用のしかたを解説しています
おすすめする理由
めちゃくちゃ具体的です。こういったプログラミングの概念に関する解説って抽象的になりがちで、ふわっと分かった気になってしまい結局正しく理解できないことが多いですが、この本では最終的にはコードや UML 図を利用して明確な答えを示してくれるので、間違って理解することを避けることができます
難しくないですか？
具体的であるがゆえに、経験したことが無い項目については理解するのが難しいかもしれません
しかし、理解できないことがあるというのを知ることは理解のスタート地点です。この本はアプリケーションアーキテクチャという全体を俯瞰した本なので、理解できなかった部分は足りていない知識です。まずはアーキテクチャの全体図を俯瞰して見れるようになりましょう
読み方
アーキテクチャはフラクタル
アーキテクチャはフラクタル構造を持ちます
システムはアプリケーションで構成され、アプリケーションはパッケージで構成され、パッケージはコンポーネントで構成され、コンポーネントはクラスや関数で構成され、それらは式や文で構成されています
それぞれのレイヤは一見まったく似ていないように思えますが、それぞれに構造がありアーキテクチャがあり、 SOLID 原則はそれぞれで応用しながら適用が可能です。そして、この本では繰り返しその応用方法を実例を混ぜながら解説しています
明確にそのような構成で書かれてはいませんが、これを意識におきながら読むことで、アプリケーションアーキテクチャへの理解が進むと同時に SOLID 原則に対する基礎と応用が身につけられるでしょう
1. プログラミングパラダイム
道具を知ることは大事です。そしてプログラミング言語の道具としての特徴を知りたければ歴史に学びましょう
構造プログラミング、オブジェクト指向、関数型。それぞれがどういう理由で発生し、どんな問題を解決したかったかを理解することで、それぞれの言語の機能をより深く理解して効率的に使えるようになるでしょう
それぞれのパラダイムを採用した言語を触ったことがないと内容を実感できないかもしれません。これらのパラダイムはコードレベルでのアーキテクチャに影響するので、最後まで読んでからここに戻ってくるとより深く理解できるでしょう
2. SOLID 原則
ここは基礎と応用の基礎の部分です
SOLID 原則に対する解説は色々ありますが、ここではかなり基礎的な解説になっています。理解が難しければ他の文献を参照にするのもいいでしょう。重要なのは、この章が単体で成立しているわけではなく、続くアーキテクチャを説明する予備知識という理解の仕方をすることです
3. コンポーネントとアーキテクチャ
コンポーネントは部品で、アーキテクチャはその組み合わせ方（分け方）です
現在のアプリケーションにおいてコンポーネントの概念は大きく変わっていますが、ここで説明されている特徴は普遍的なもので SaaS からマイクロサービス、コードレベルでのモジュールまですべてに適用できるでしょう
アーキテクチャに関しては題材が縦横無尽に飛ぶので、未経験で読むと理解が難しいかもしれません。自分の経験と照らし合わせて分かるところから読んでいくのがいいでしょう
UML 図は慣れていないと読みにくいかもしれません
UML 図というのは構造を明確に記述するための決まりで、基本的に構造は「配置と分割と接続」で構成されます。例示されたサンプルがわかりにくい場合は、なにが分割されていてどう接続されているのか、を意識する事で読み解きやすくなります
また、アプリケーションの構造を、水平方向の分割であるレイヤとレイヤ内での垂直方向の分割であるコンポーネントで分け、縦横のグリッド的な構造で考えてみると少しだけ理解しやすいかもしれません
5. 詳細との付き合い方
詳細という概念についてはあまり解説を見ないのですが重要です。なぜでしょうか？
そもそもエンジニアが日々実装しているのは詳細です。しかし、アーキテクチャにおいては詳細を考慮してはいけないと言います
詳細とは実装です。 MySQL で書くのか Postgres で書くのかにアーキテクチャは立ち入りません
同時に詳細に設計が依存してしまうことがあります。極端な例で言うと Rails はアーキテクチャを規定します
別の本になりますが、「 Design It! 」と言う本の「 2.1.2 曖昧さを保つ」と「 6章」でアプリケーションの自由度・可能性を保つために可能な限り判断を遅らせることの重要さが説明されています
詳細を知らないと設計上の判断はできません。詳細をただ実装としてみるのではなくアーキテクチャ的な視点ではどのように読み解くのかを理解することで、より深くそれぞれの詳細を紐解くことができるようになるでしょう
最後に
ソフトウェア開発というものは難しく、構造を制御して知識の露出を絞り、コンポーネント間の繋がりを限定して人間が認知可能な構造を維持しないとすぐに破綻してしまいます
この本は著者であるアンクル・ボブが、自分の経験の中から 継続的に開発されるソフトウェア をどうやってクリーンな状態で維持していくかを、そのために最も重要であるアーキテクチャという視点で紐解いた本です
日々の業務でボトムアップの知識は自然と増えていくと思いますが、アーキテクチャ視点でトップダウンに統合的な視点は意識して取り組まないと育っていきません。ボトムアップとトップダウン両方の視点を手に入れて成長につなげてください
