『Clean Architecture』を読んでいて、これを実現するには上流工程の順番で開発をすればいいのではと思いました。
Clean Architecture とは上の図で説明されるソフトウェアコンポーネントの設計思想です。フレームワーク・データベース・画面などを「細かい話」として脇に追いやって、業務を中心に据えているところが特徴です。業務のモデルを表す Enterprise Business Rules が中心にあって、業務アプリケーションがする仕事を Application Business Rules として記述し、Interface Adapters が業務アプリケーションと細かい話を結びつけます。そして、Clean Architecture は、コンポーネント群のビルドの依存関係も、外側から内側にと、アプリケーションが業務に依存するようにせよと言っています。
さて、この Clean Architecture を実現するためにはどうしたらよいのでしょう。コンポーネント図を Clean Architecture に従って描いて、Clean Architecture を維持するようにコントロールをするのでしょうか。そのやり方でもよいのですけど、おそらくほとんどの人は Clean Architecture をやろうとおもったら、中心にあるコンポーネント、業務のモデルから順に考えて開発を進めるということをするんじゃないかなと思います。先に作ったものは、後に作ったものに依存されるので、自然の Clean Architecture のコンポーネントの依存関係になります。
また、Clean Architecture は細かい話を後回しにしようという開発のアプローチの方法でもあります。設計スタイルではなくて、低レベルな話からボトムアップに決めていくのではなくて、業務すなわちシステムの目的といった高レベルな話から決めていきましょうというアプローチの方法を述べているのだと思います。そのため、開発の順番で Architecture をコントロールするのが自然なのではと思うわけです。
しかし、業務を中心に考えていくのは、普通の上流工程やりかたと同じではないかとも思うわけです。
要件定義をしようとしたら、すなわち、それらが満足されたら問題が解決するのだという一覧を作ろうとしたら、まずは問題を分析して問題を理解することを試みますよね。業務アプリケーションならば、ビジネスモデルはどうなっていて、どういう登場人物がいて、彼らは何をやりとりしているのかみたいなことを読み解くことからするんじゃないかな？
問題を理解したら、次は解決策を考えます。一般には新しく機能を作るのが開発での解決策になるかと思います。新しい機能で考慮しなければならない使い方や無視してもよい使い方を勘定して機能の要件を決めます。
次は DB のスキーマを決めたり、I/F の仕様を決めたりしますね。こららを世間では基本設計というのかな。
1, 2, 3 の結果を、それぞれコード化したのが、Enterprise Business Rules, Application Business Rules, Interface Adapters に対応するのではないのだろうか。つまり、上流工程の進め方と Clean Architecture に類似性が見られます。もしかしたら、要件定義から基本設計にオーバラップして、決まっているところから結果をコードに表現していくみたいなことができるかもしれません。ただし、手戻りもするだろうし、作るのに夢中になって、何を実現べきかを考えるのが疎かになりそう。
いずれにせよ、今回気づいたのは、開発の進め方と Architecture は関連するもので、開発の進め方に応じて Architecture を決めたらいいということです。
