読書ノート『Clean Architecture』その3：アーキテクチャ（独立性と境界線）

I〜II部で粒度に関わらない普遍的な法則を、Ⅲ〜IV部で小さいレベルの構造について説明していたが、Ⅴ部ではいよいよ本題のアーキテクチャについて取り扱っている。

15も章があるので途中で一旦切るかも。

アーキテクチャとは？

15章で纏められている。本書における定義は以下の通り。

ソフトウェアシステムのアーキテクチャは、それを構築した人がシステムに与えた「形状」である。
（中略）
アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである。
（中略）
アーキテクチャの主な目的は、システムのライフサイクルをサポートすることである。

これはI部でも述べたとおり、エンジニアは振る舞いと構造の双方に責任を持つべきという話につながる。

ソフトウェアは変更されるものだから、ライフサイクルをしっかりサポートすることはいまいまの振る舞いよりも大事なことである。

本章では選択肢を残すということが繰り返し述べられている。

方針だけを策定し、重要ではない詳細を後ではめ込めるようにすることがソフトウェアをソフトに保つ上で欠かせないことだからだ。

データベース、Webサーバ、フレームワークも『重要ではない詳細』に入る。

自分のシステムを組むときにフレームワークをどうするのかと聞かれることは結構多いのだが、入れたければ後で入れればいいぐらいのスタンスで行っている。コンポーネントの実装チームが別でいる場合はぶっちゃけ任せてる。

ところで、アーキテクトとはプログラマであって、書く量が減ったとしてもコード書き続けろよということがかなり強い語調で書かれている。

上流工程担当は設計だけやっていればいいという風潮に相当キてるようだ。

実装を全部下請けに投げて上流工程だけやってる某国の大手SIerに是非ともご意見伺いたいところである・・・

独立性

16章の内容。

優れたアーキテクチャはシステムのユースケース・運用・開発・デプロイをサポートすると書かれている。

『ユースケース』がいきなり出てきて面食らうが、振る舞いの大枠のことである。先の章でアーキテクチャは振る舞いに関しては殆ど影響を与えないと述べられているが、ユースケースに関してはビジネスに係る大枠の方針であり、アーキテクチャが特徴づける。

優れたアーキテクチャはいい感じにバランスが取れたコンポーネント構造を持っている。「ね、簡単でしょ？」と煽って来るあたりお茶目である。

実際には全てを把握するのが難しい状態で、いい感じに独立性をもったコンポーネントを作るにはどうしたら良いか？

ユースケース観点

１つは『レイヤーの切り離し』。ユースケースっても『フォームにメアド入れる』てのは変わりうるが『発注処理をする』てのはビジネスの本質で変わりにくい。だからレイヤー分けして独立性を持たせるべきって話。

１つは『ユースケース切り離し』。各水平レイヤーを垂直に分離したもの。よく言われる参照系と更新型の分離ってのも多分ここに入る。

運用観点

結論から言うと運用に影響するようなより細かい単位の『切り離し方式』に関しては選択肢を残しておくことが望ましい。

プロジェクトやプロダクトフェーズで適切な分離レベルが変わってくるからだ。なんでもかんでもマイクロサービスアーキテクチャにすればいいというわけではないという話。

開発・デプロイ

ユースケース観点で分離されたコンポーネント単位で作業すれば衝突は避けられる程度のことがサラッと書いてある。

境界線を引く

17章〜19章の内容。

早すぎる決定との結合は非常にマンパワーを消費する。
境界線は『重要なもの』と『需要ではないもの』の間や変更の軸が有るところに引く。

システムをコンポーネントに分割して、依存性逆転の原則と安定度抽象度等価の原則を適用するとコアとなるビジネスルールに向かって周辺コンポーネントが依存するようになる。

境界線の引き方には下記のように色々あり、レイテンシなど考慮して使い分ける。

・ソースコード単位：単一の実行ファイル
・デプロイコンポーネント単位：ライブラリなどに分ける
・ローカルプロセス単位：メモリ空間を分けることができる
・サービス単位：最も強い境界の引き方

また方針にも大小があるので、それに応じて階層レベルを分けて対処する。

まとめ

V部は長い上に内容が濃いので一旦ここで切る。

下位の構造レベルに対して適用していた基本原則はそのまま適用できるが、アーキテクチャレベルだとシステムの指針を決定し、プロダクト・ライフサイクルを決定づけるという将来に渡った意義がある。

そのため『重要ではない詳細』の決定は下位構造で実現し、そのため振る舞いに関しては殆どアーキテクチャにおいて決定しない。

個人的にはフレームワークが『重要でない詳細』であるという点は大事だと思う。

特定のフレームワークを持ち上げ、導入すれば問題がまるっと解決するかのような言説をしばしば目にするが、しかし多くのプロダクトは根っこに不健全なライフサイクルを抱えているのではないだろうか？

フレームワークは確かに強力だが、高価を発揮するのは問題解決よりも効率化の場面のように思う。

プロダクトの初期段階でフレームワークを聞かれることは非常に多いのだが、『後で決める』『なんでもいい』と答えるようにしたい。