「クリーンアーキテクチャ」選択を残して開発をするための設計

気づいたら時は流れ、アドカレ16日と＋X日になっていた...

というわけで最近また話題になっていたクリーンアーキテクチャについてです。

書籍『Clean Architecture』を読んで理解すると「クリーン・アーキテクチャで作りました」という発言は出なくなる。わかる。 pic.twitter.com/LkrWiNF1IP
— Takuto Wada (@t_wada) 2024年1月11日

このツイート、私も実際にクリーンアーキテクチャを読了して「わかる！！！」となったので、その辺りを話せればなと思います。

このよく見るあの図だが、本書では1度しか登場していません。また、文脈としてもヘキサゴナルアーキテクチャやDCIアーキテクチャ、BCEなど様々なアーキテクチャの特性を統合したものとしている。

すなわち、「クリーンアーキテクチャ」というアーキテクチャというものはそもそも存在していません。では、本書が語っているクリーンアーキテクチャとは何なのか、なぜ行うのからに触れながら個人的に気になったところを書いていこうと思います。

なぜ設計を考える必要があるのか

ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

様々な設計に関する本で語られている様に、この書籍でも技術的負債を溜め込まずリリースごとに労力が増えるといった状態になるのを回避することを考えている。

変更の難易度は、変更の形状ではなく、変更のスコープに比例しなければいけない。

これは非常によくある悪い状況の見方だなと感じる。

例えば画面に表示する1文を変更する要望があったとする。コードを見てみると、その文字列を別のところでも使っていてそっちの修正も必要になってきて、あれDBにも保存している？という厄介な問題になることがある。

これは変更の形状に対して、難易度が圧倒的に高い。よく設計が出来ていればスコープを文字程度簡単に修正し、ビジネスロジックの大きな変更など大変だと思われるものに、その通りの難易度が伴う形になる。

個人的にこの書籍で最も語りたいところがこの部分だと感じる。

よく見るアーキテクチャもこの部分の影響を強く表しているという風に感じますね。

関心事をドメインなのか・技術なのかに分離し、ドメインが技術に依存しない様にコントロールする。これをするために、オブジェクト指向の様々な手法を使うことが記載されているのが本書になります。

この様に関心事を分離し、依存関係のコントールをすることで"ドメインに関してはフレームワークも含め、全てから独立させるべき"ということが実現します。

さてこれができると何がいいのか、ドメインにフレームワークやライブラリなどが依存している場合、それらの影響を受けることになります。それがバージョンアップならばまだ良いですが、放棄でもされた時には溜まったものではありませんからね。

また、ドメインを独立させるためにフレームワークの選定にも注意を促しています。

フレームワークの作者にとって、自分の作った基底クラスを大勢のユーザーが継承することほど、自尊心が満たされることはない。

少しマサカリのようだが、この様な記載がある。一旦モヤモヤを取り払い、性善説的に「大勢が基底クラスを継承することで新たな価値を提供しやすくなるために基底クラスを継承させたがっている」とでも解釈しておこう。

フレームワークをドメインに依存させない方法は簡単で、Entitiesなど内側に入れないこと、円の外側に対してのみ使用する。

この書籍はソースコードレベルの話ではなく、DBや提供する方法も含め"変更を容易にする設計をどの様にするか"という話になっています。

その中でデプロイという話も入っており、昨今のマイクロサービスの話が脳裏をよぎった。さて、ここでマイクロサービスでサービスを作った時、いざリリースの時に起動のタイミングなどが重要になったりする。

関心事を適切に分離することで、DBや提供方法といった"プロダクトの価値以外の選択肢を残すことができる"ことも利点となります。

私個人の感想ですが、「作りました」と言っている時点でクリーンアーキテクチャではないと言えるのでは？と感じました。

なぜならばクリーンアーキテクチャとは、選択肢を常に残すことでプロダクトの提供方法といったビジネス的な決定や、技術選定を遅らせたり、移行のしやすさを保っているソフトウェアだからです。

なので、クリーンアーキテクチャかどうかは実際に運用に乗せ様々な課題を軽く往なせるかというところで判断するしかないのだと私は思っています。