いまさら『Clean Architecture』の感想文

手遊びで Go でバッチ処理を書いてるのだが，ちょっと作業に飽きてきたので，前々から書こうと思っていた『Clean Architecture』の感想文をやっつけてしまおう。

Robert C. Martin（通称ボブおじさん）による『Clean ◯◯』シリーズのひとつが『Clean Architecture』である。 この本の中身については以下の解説記事が分かりやすい。

• 世界一わかりやすいClean Architecture - nuits.jp blog

本記事を読むくらいなら上のリンク先記事を読むことを強くお勧めする。 以上！

では面白くないので，続きを。

『Clean Architecture』の面白いところは，各トピックが非常に短い文に凝縮されているところ。 たとえば「構造化プログラミング」「オブジェクト指向プログラミング」「関数型プログラミング」の3つのプログラミング・パラダイムについて

構造化プログラミングは、直接的な制御の移行に規律を課すものである。

オブジェクト指向プログラミングは、間接的な制御の移行に規律を課すものである。

関数型プログラミングは、代入に規律を課すものである。

などと，ざっくりした文で締めくくっている。 いや，ざっくりしすぎだろう（笑） こういう解説を読んでしまうと， GOTO は悪とか継承がどうのとか多態化だの単態化だの不変だのそれっぽい用語を並べて語るのが馬鹿らしくなる。

世の中に山ほどのプログラミング言語があるが，すべてこの3つのパラダイムの組み合わせで成り立っていて，これらが課す規律または制約がプログラム・コード→コンポーネント→アーキテクチャにどう影響を及ぼすのか，というのが言語を語る（騙る？）際の最重要ポイントだと思う。

『Clean Architecture』の主題である「アーキテクチャ」にしてもそう。 この本ではアーキテクチャを「システムに与えた「形状」である」とし，アーキテクチャの形状の目的は「ソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである」と述べ，さらに

それらを容易にするための戦略は、できるだけ長い期間、できるだけ多くの選択肢を残すことである。

と締めくくる。 ここで私はあの名作を思い出すのである。

公理によって与えられる暗黙の制約。この制約が集合の要素同士をしっかり結びつける。単純にしばるのではない、相互に秩序ある関係を結ぶ。言い換えれば――公理によって与えられる制約が構造を生み出しているのだ

つまり，プログラミング・パラダイムによって与えられる「制約」が巡り巡ってアーキテクチャという「構造」を生み出す。 おー，円環が繋がったぞ（笑）

個人的には「第32章 フレームワークは詳細」の

フレームワークなんかと結婚するな！

でバカウケしてしまった。 うんうん。 フレームワークとは距離のあるお付き合いをしたいものである（笑）

以前に『ユニコーン企業のひみつ』の読書会の話を書いたが，私は『Clean Architecture』も同時に読み返していた。 プロダクトのイテレーションを継続するためにはアーキテクチャの「できるだけ多くの選択肢を残す」戦略が必須だと思ったからだ。

こんな感じで，私はちょいちょい読み返している。 特に設計に迷ったときとか，決して「正解」を教えてくれるわけではないけど，プロダクトやシステムにとって何がコアで何が「仔細」なのか，設計が外道に落ちないようストッパーとしてこの本は効いている。

【2022-12-10 追記】「ちょうぜつエンジニアめもりーちゃん」を読め！

祝♪ #ちょうぜつエンジニアめもりーちゃん 単行本化！

というわけで，『Clean Architecture』じゃフワッとしていてよく分からんって方やこの記事の最初に挙げたリンク先よりもう少し詳細な解説書はないのか？ って方には田中ひさてるさんの『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』を併せて読むことをお勧めする。

特に第9章コラムにある

パラダイムがじっくり待ってくれているこの時代は、学習者にとっては大きなチャンスです。変化が激しすぎてついていけないなんてことは、もうありません。必要なことは出そろっていて、いい意味で枯れたものを学べます。

というのは本当にそのとおりだと思う。 こういった良書を時間をかけて理解していくことが大事である。

ブックマーク

• プログラミングを独習するには10年かかる（Teach Yourself Programming in Ten Years 日本語訳）

参考文献