読書ノート『Clean Architecture』その4：アーキテクチャ（クリーンアーキテクチャ）

ビジネスルールの取り扱い

20章の内容。

１つはエンティティ。エンティティは『最重要ビジネスデータを操作する最重要ビジネスルールを幾つか含んだオブジェクト』である。

エンティティはビジネスそのものであるから、システムから独立したオブジェクトであるのが望ましい。

一つはユースケース。ユースケースは『自動化されたシステム使用する方法を記述したもの』である。

ユースケースにはアプリケーション固有のビジネスルールが記述される。

アーキテクチャの決定要因

21章の内容。

例の同心円の図も出てくる。

アーキテクチャはユースケースに基づいて決定されるべきであり、そのように作ればテスト可能なアーキテクチャとなると言ったことが書かれている。

『WEBシステム』というのも配信手段でしかないのでアーキテクチャ決定に引っ張られてはいけないし、フレームワークに引っ張られても駄目。

特にフレームワークに関してはこれでもかというほどしつこく否定している。

よほど恨みがこもっているようだ・・・。

クリーンアーキテクチャ

22章の内容で20、21章のまとめ。

有名な同心円の図が出てくる。

ここまで散々述べたとおり、依存関係をきちんと管理することこそが重要であり、具体的で変わりやすい下位のコンポーネントが、本質的で安定した上位に依存すべきという話をしている。

より上位から並べる。

エンティティ：最重要ビジネスルール
ユースケース：ソフトウェア固有のビジネスルール
インターフェイスアダプター：実装向けのデータ構造に変換コンポーネント
フレームワークとドライバ：外的要因

境界線を超えるデータ形式は上位コンポーネント側が扱いやすいようにする。

まとめ

アーキテクチャに関する基本原則に関してはここまでなので一旦切ります。

特に上位コンポーネントに関して詳しく書かれてました。

上位コンポーネントはとにかく余計な詳細を排除して下位コンポーネントに追い出す必要があるようです。

徹底的にフレームワーク依存を上位コンポーネントから追放しようとする強い意志が感じられました。

このあとは境界の話再びと、下位コンポーネントの話になってきます。