人生を豊かにするためにかの有名なRobert C. Martinの Clean Architecture を遅ればせながら読んだ。
探せばいくらでも優良な Clean Architecture の解説記事が出回っている(ゆえにこの記事になにも新規性はない)し、自分がそこまで咀嚼できていないので詳細を語ることはしないが、なんとなく心打たれた印象の強いものについて残しておきたい。
原則
本書で何度も繰り返し出てくるのは detail, policy, boundary, abstract だった。 SOLID原則をコードレベルではなく抽象度のレベルをあげてビジネスルールにまで持ってこようという話であると理解した。
要は大昔から言われているDIPだのSRPといったメンテ前提のコードとして適用したい原則を守ろうということで目新しい情報はなかったけれども体型的に説明されていたおかげでものすごくすんなり入ってきた。
Clean Architecture がどうのというより、まともに設計しようとしたらこうなるよな。と言うものだった。 Clean Architecture はフレームワークではなくて単なる鉄則と言うだけだったのが意外だった。それゆえ難しいことは言っていない。
日頃自分がある程度のコードを書くときに意識してること、特にテストのしやすさを担保するためにDI可能なようにしておくなどが改めて書かれていた。本書が世の中に広く持て囃されている理由はこう言うプログラマが普段意識的にも無意識的にも体験していることを明文化されているところにあるんだろう。
Boundary
本書では特に boundary についての言及に重点が置かれていたと思う。 boundary がなんなのかは本書の文脈上でも全く単語の意味通りであるから割愛するとして、boundary を意識することが上記原則を適用するにあたり肝要であろうことがうかがえたし、実際これを実践するとなるとそれなりに訓練がいるものであった。
特に依存の矢印を見たときの direction については読者の注意を促すようなものが書かれていたし、まあ、そうだよなと言う感じ。
Clean Code と合わせて読む意味
正直な話、心構え以上のことが書かれているわけではないと思ったのでそう言う意味では同著者の Clean Code と立ち位置は本質的にかわらんだろうなと感じた。
Clean Code: A Handbook of Agile Software Craftsmanship (English Edition)
- 作者:C., Martin Robert
- 発売日: 2008/08/01
- メディア: Kindle版
Clean Architecture が概念的なことに書かれているのに対して Clean Code はコーディングよりの指南書という様相を呈する。 Clean Code で書かれていることはそれなりに多岐にわたるんだけど2冊とも同じで依存には気を使えと言っている。 それ以外にも Clean Code では命名規則がどうとかデータ構造の設計方法とかトピックはあるので2冊とも読んで無駄ということはないと思うけどまず最初は Clean Architecture を読んでからの方がいいかなと思う。 Clean Code もコーディングする上での指針としてとても参考になることが書かれている。
極めるとすると
Clean Architecture で有名な図で4層の同心円がある。 あれは一番外側の層が置換(DI)可能なものであって、より内部に行けばいくほど抽象度が高くビジネス要求を表すことになり、依存の流れを表すことになっている。 Clean Architecture を極めるとする最深部の Entity は特定のプログラミング言語に固定されないように汎用的なデータフォーマットで定義されるべきだろうと思った。 それが yaml なのか toml なのか protobuf なのか xml なのかはわからないが、一定のルールをもつ構造化された自然言語で記述されるのが理想なんだろう。 それがいわゆるユビキタス言語とそれを使って表現されるビジネス要求だったりするはずで、それをうまく体系立てようというのが DDD なのだろうか。DDD はこの文章を書いてる時点で知らないのでわからない。
言いたいことは、Clean Architecture でビジネス要求というのはシステム化されようがされまいが関係なく存在することで、むしろそれ自体を気にしては行けないということである。 Entity の表現方法に正解はあるのか、DDD の原典ぽいエリックエヴァンスのあれを読んで見たいと思う。
役に立つか
自分の携わるプロジェクトに関わるエンジニア全員に本書を読ませて共通認識を持った上でないと噛み合わないんだろうなと思うことはあった。 ただ、先に言ったように本書は基本的に原則まとめでしかないのでまあ、原則知っておこうやという感じなので概ね役に立つだろうと思う。
そんな人間がいるかわからないが原則を盲信するなみたいなことを仮に言われたとしても、原則を理解してますか？と返す刀で同じ土俵に立ってるかどうかの判断をする試験紙としては使えるだろう。
また、適当に書いて適当に動いたり動かないとか、めちゃくちゃテストしづらいみたいなコードが簡単に産み落とされるみたいな災禍はお互いのレビューにより起きづらいだろう。
