LOBでGopherをやっているChifung Cheungです。
最近Gopher界隈でClean ArchitectureだったりDDDだったりでやる風潮が強まっているが、
「別にどうでもいいじゃない？」と主張したいだけです。
- 「まだClean Architectureで消耗しているの?」というタイトルをつけたが、Clean Architectureに限らず、DDDなどのアーキテクチャも似た問題があります。
- Golangに限る話です。
- ベンチャー企業での話です。
そもそもなんでClean Architectureを使う
主な理由は、持続可能な開発 にしたいです。いわゆる、開発規模の「Scale」をしたいのです。
Clean Architectureの信者は、コードを書く前にまずはClean Architectureを導入する、そのシルバーバレットがあれば、プロジェクトが簡単にスケールできると信じているでしょう。
もちろん、現実はそう甘くない。
スケールの確認ができる前に、Clean Architectureを導入したらすぐ問題が出る。
- 一つの機能を開発するには、Interface、Domain Models、Adapters、Usecaseなどの登場人物が揃えないといけない。どの機能をどのドメインに置くべきを考えるのが頭にいっぱいで迷い子になる。
- 関心が細かく分離することで、一人ですべてのドメインをカバーしにくくなる。
- コンポーネントとインターフェイスが多くて、すべてのテストを書くのが時間かかる。
- Clean Architectureを導入すれば自分の書いたソフトウェアがスケールできると信じて他の問題を無視してしまう。
いわゆる、問題解決するために導入するために導入したソリューション自体が、プロブレムになってしまう。
じゃ、どうすればいいのか
趣味で常にGitHub上の様々な優秀なGolangのOSSを読んでいます。一つ分かったのは、
いくら複雑なソフトウェアであっても、Clean Architectureを使っていません。
GolangのカリスマDave Cheneyは最近のブログで、持続可能な開発したいならGolangを書く時にこの３つの原則を守るべきと書きました。
- Simplicity
- Readability
- Productivity
なぜかというと、Goはソフトウェアエンジニアリングの問題を解決するために開発された言語であって、Go自体がソリューションです。
優秀なOSSはほとんどこの３つの原則を守って様々な人を開発に巻き込んでプロジェクトが成長できたわけです。
逆に、下手にGoでClean Architectureを入れると、この三原則を全部違反してしまう。
- Simplicityなし：不要なコンポーネントが多い、過度な抽象度、本来簡単であるべきソフトウェアの複雑度が一気に上がる
- Readabilityなし：一つの機能の構成部分が多くて、ロジックを理解するために幾多のファイルを全部読まないと理解が不可能。アーキテクチャの習得コストも高まり、読む側の負担になりがち。
- Productivityなし：GoにはまだGenericもない、自動生成のあるライブラリもない。Clean Architectureに対応するには、コピペか下手な自作ライブラリか他の手段がない。余計な工数が発生する。
Clean Architectureが悪？
いいえ、悪いのは問題の制約と本質を考えずに過度な設計をする人間です。
自分もClean Architectureを含んだ様々なアーキテクチャやフレームワークを使ったことがありますが、どちらでも適用範囲があります。
Goはそもそも特定のドメインの問題を解決するための言語なので、
Goの原則を守らない使い方をするなら、絶対他の言語にしたほうがいいと思います。
「Goに入ればGoに従え」
Merry Christmas