よしたく blog

ITエンジニアとして自分が知らなかったことをまとめています

Design It! 輪読会 6章 「アーキテクチャを選ぶ(君がアーキテクチャに選ばれる前に)」

今回は6章をおこないました。6章はアーキテクチャを選ぶというタイトルで話が進んでいきますが、個人的にはこの副題が大切な気がしました。注意して読むと「アーキテクトに選ばれる前に」と言う、任命される前にという意味ではなく「アーキテクチャに選ばれる前に」となっており、振り回されず能動的に管理していこうというニュアンスがあるように感じたためです。

www.oreilly.co.jp

この章で伝えたいことを整理する

先の7章を読むと個別のアーキテクチャの詳細な話が展開されており、この6章では前段として個別のアーキテクチャを選択する注意ポイントやどう選択していくかという話がされていた。

まず、アーキテクチャ上何が必要かを広い視点から探求するために「発散」「探求」「収束」と言う手順が取られていた。これはアイデア出しでも使われるブレインストーミングに近いものだと捉えた。アーキテクチャの観点から見て珍しいと思ったのはデプロイの方法についても探求してみるという点であり、システムを組み立てるだけでなく今後の継続的な観点からも必要なものであると感じた。

発散させ収束していく中である程度の自由もありながらもやはり制約というものも必要になる。ここでは技術的な面とビジネス的な面が取り上げられていた。技術的な面はPythonで組み立てることになったのでJavaフレームワークは使えないと言った制約であり、ビジネス的な面は今月末にリリースをしなければいけないため、使い慣れている技術だけでリリースを使用(=新しいものは取り入れないでやろう)と言ったことであった。最終的にアーキテクチャを選んでいくに当たり、各アーキテクチャの特徴を比較して選択していく。

分解した要素1つ1つが自分のやらなければいけない責務をもっているかチェックする必要もある。そういった時の確認方法としては要素責務カタログを作成すると有効であることも書かれていた。

最後にはアーキテクチャは組んだら終わりではなく、組んだ後の変化にも対応しなければならないことが書かれていた。そういうときのために判断をできる限り遅らせたり、クリーンアーキテクチャで学んだSOLID原則をアーキテクチャにも対応させることが重要であることが書いてあった。そうすることで柔軟性をもたせることができる。