Clean Architecture 達人に学ぶソフトウェアの構造と設計

本日読了。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

ビジネスロジックを最も固定したものと位置づけ、その外にアプリケーション固有ロジック、さらに外にプレゼンターやコントローラーやゲートウェイなどを、最も外にUIフレームワーク，Web，デバイス、DBなどを置く。外から中にコール（依存）はできるが、逆はできない。逆を行う場合は、外部を抽象化・入れ替え可能にしたインタフェースを介して行う。アーキテクチャー設計は、外部は最も後に設計し、内部は外部の選択（RDBなのかnoSQLなのか等）には依存しないように作る。すなわち、DBをどうするかとか、フレームワークに何を使うかに依存しない設計を行い、それらは最後になって決めれば良い、とする。

設計の原則（SOLID原則）。SRP（単一責任の原則）、OCP（オープンクローズドの原則）、LSP（リスコフの置換原則）、ISP（インタフェース分離の原則）、DIP（依存関係逆転の原則）。各コンポーネントは凝集性を持つ。

徹底していて、ひとつの考え方としては面白い。しかしながら、フレームワーク非依存を徹底するとか、逆にビジネスロジックを相対的に変わらないものと位置づけるのは、いまどきどうなんだろうか。。ビジネスそのものが変革しますので、フレームワークをうまく選定すれば、そちらの方が寿命が長いのでは。

若い頃に「RDBなんて不要、と主張したけど負けて、会社を辞めてやった( ･´ｰ･｀)どや」とのことだが、RDBにすることでオンラインバックアップが容易になるとか、考えなかったのかな・・。