Robert C. Martin 『Clean Architecture』

この本を読む上で一番の疑問。Clean Architectureはcleanなアーキテクチャーのことを言っているのか。それともClean Architecture という1つの造語・名詞を指しているのか。

Clean Architectureを表した有名な図がある。

図題は「The Clean Architecture」となっている。本にも同図が挿入されている。同図下にあるキャプションには「Figure 22.1 The clean architecture」と記載がある。こちらは小文字表記だ。

個人的に、clean architectureは小文字表記が正しいと思っている。著者が図で表しているアーキテクチャーはあくまで一例と理解し、clean architectureはプロジェクト毎に模索すべき、というのが自分の意見だ。

本が読者へ一気通貫して送るメッセージは単純だ。実装に依存にせず、インターフェースに依存する。境界を超える依存方向は一方向にする。

頭ではわかっても、実際にコーディングするのは難しい。アーキテクチャーレベルではレイヤー間の依存関係だけ考慮すれば良いが、実装レベルではレイヤー内でのコンポーネント・オブジェクト関係まで考えなければならない。

どんなにcleanerにできても、absolutely cleanに実装するのは現実的に不可能。

本の内容でよく理解できなかったものが第19章で紹介されていたlower-higher levelという表現。一度、本を読み返すと、至って端的にそれが何か書かれていた。

“A strict definition of ‘level’ is ‘the distance from the inputs and outputs.’”

加えて次のような宣言もある。

“Lower-level components should plug in to higher-level components.”

プラグインを動詞して使用した場合は、プラグインは主語側になるのか。目的語側になるのか。落ち着いて読み解くと、主語側、つまりは、lower-level componentsがプラグインになる。

lower-higherという表現はややこしい。一般的なレイヤードアーキテクチャーは下の図のように表わされる。

レイヤードアーキテクチャーでは高いレイヤーが下のレイヤーに依存する構成になっている。lower-higher level componentsの依存関係とは高低差による依存方向が逆の現象が起きる。

higher-lower level components ≠ higher-lower layers

この不等式が頭に入っていないと混乱する。

それからもう一つ。ソフトウェアアーキテクトとシステムアーキテクトは別物。この本はソフトウェアアーキテクトの本。

***

このブログを書いている土曜朝八時半過ぎ。ノマドしている建物一階ロビーにあるカフェで作業をしているとスタッフから「お腹空いてます？」と声をかけられた。「はい、空いてます」と元気な口調で返答する。しばらくするとスタッフが朝食プレートを運んできた。「一人お客さんが来なかったので。」てっきり他のお客さんからもらった茶菓子でもいただけると思ったのだが、まさかプレートごとご飯をもらえるとは。

執筆作業を止め、おいしく食事をいただく。朝ごはんは既に食べていた。これは昼食だ。九州の野菜はうまい。