勉強まとめ

1. Clean
Architecture
第Ⅴ部
アーキテクチャ Part4

2. 前回まとめ
- 方針とレベル
- ソフトウェアシステムは方針を示したものである
- 方針は更に小さな方針に分割される
- どのような場合でも、下位レベルから上位レベルへ依存するように設計する
- ビジネスルール
- ビジネスルールとは、手動でもビジネスマネーを生み出したり節約したりするルールや手続きのこと
- 最重要ビジネスルール /最重要ビジネスデータ = エンティティ
- ユースケース = アプリケーション固有のビジネスルール
- 叫ぶアーキテクチャ
- 優れたアーキテクチャはドメイン、ユースケースを中心にしている
- FWは強力で便利だがアーキテクチャを乗っ取られてはいけない
- テストはフレームワークを使うことなく全てのユースケースのユニットテストを実行できる

3. - クリーンアーキテクチャ
- プレゼンターとHumble Object
第Ⅴ部：アーキテクチャ Part4

4. 第1章：クリーンアーキテクチャ
- アーキテクチャのアイデア
- ヘクサゴナルアーキテクチャ
- DCIアーキテクチャ
- BCEアーキテクチャ
- レイヤードアーキテクチャ (勝手に記入)
- いづれも関心事の分離
- それぞれ、少なくともビジネスルールのレイヤーと、ユーザーやシステムとのインターフェイスと
なるレイヤーを持っている

5. - フレームワーク非依存
- アーキテクチャは FWの制約で縛るのではなく、 FWをツールとして利用する
- テスト可能
- ビジネスルールは、 UI/DBなど外部要素がなくてもテストできる
- UI非依存
- UIはシステムの他の部分を変更することなく、簡単に変更できる
- データベース非依存
- ビジネスルールは DBに束縛されないので、 MySQL/PostgreSQL 等いずれにも置き換えれる
- 外部エージェント非依存
- ビジネスルールは外界のインターフェイスについては何も知らない
第1章：クリーンアーキテクチャ

7. 第1章：クリーンアーキテクチャ
- 依存性のルール
- 最も重要なルールは「依存性のルール」
- 内側の上位レベルだけに向かっていなければいけない
- エンティティ
- 最重要ビジネスルールをカプセル化したもの
- メソッドを持ったオブジェクトでも、データ構造と関数でも
OK
- 企業にある様々なアプリケーションから使用できるなら、
エンティティは何でも構わない
- ユースケース
- アプリケーション固有のビジネスルールが含まれる
- エンティティに入出力するデータの流れを調節する
- ユースケースの目標を達成できるように、
エンティティに最重要ビジネスルールを
使用するように指示を出す
- インターフェイスアダプター
- 外部とのデータを相互変換するアダプター
- DBについては何も知らない
- DBがSQLであればこのレイヤーに限定する
- フレームワークとドライバ
- FWやツールで構成されている
- 通常このレイヤーにはコードをあまり書かない
- 書くとしても次のレイヤーとやりとりするグルーコード

8. 第1章：境界線を越える
- 簡単にいうとDIPでレイヤーを保護
する

9. 第1章：境界線を越えるデータ
- 境界線を越えるデータは、単純な構造で構成される
- 好みに応じて、オブジェクトやハッシュマップ
/単なる関数呼び出しにすることができる
- EntityやDBをそのまま渡すことはしない
- 依存性のルールに違反してもいけない
- DBデータをそのまま境界を超えて渡すと、円内側が円外側を知ってしまうことになる

10. 第1章：典型的なシナリオ

11. - Humble Objectとはデザインパターンの1つである
- PresenterもHumble Objectパターンの一種
- テストしにくい振る舞いと、テストしやすい振る舞いを分離する
- 内容は非常にシンプル
- 一つのモジュールは「 Humble(控えめ)」
- もう一つは残りのテストしやすい振る舞い
- 通常UIのテストは難しい
- しかし、Humble ObjectパターンでPresenterとViewに分けてシンプルに
第二章：プレゼンターとHumble Object

12. 第二章：プレゼンターとビュー
- ViewはHumble Object(控えめ)
- イベントと渡ってきたデータの表示のみ
- つまりデータの処理はない
- Presenterはテスト可能なオブジェクト
- appからデータを受け取り、 Presenter用で適切にフォーマットして ViewModelに配置
- PresenterにDataオブジェクトを渡して、画面に日付を表示させる
- PresenterにCurrencyオブジェクトを渡して、適切な桁数と通過記号をつけてフォーマットする
- ボタンをグレーアウトする必要があれば、 PresenterがViewModelに適切なフラグを設定する
- 画面に表示するもの、 appが制御するものは全て、 ViewModelに含まれる文字列・真偽地・列挙型と
して表現する

13. 第二章：テストとアーキテクチャ
- テスト容易性が優れたアーキテクチャの特性
- Humble Objectはその好例
- 振る舞いをテストしやすい部分と、そうでない部分を分割することが、アーキテクチャの境界の
定義につながり、PresenterとViewもそうした境界の1つ
- だが、他にも境界は存在する

14. 第二章：データベースゲートウェイ
- ユースケースインタラクターとデータベースの間にある
- appがDBに対して実行するCRUDのメソッドを含んだポリモーフィックインターフェイス
- appがある日付のログインユーザーの名前を知りたいと思えば、 UserGatewayインターフェイスに、
getNamesOfUsersWhoLoggedというメソッドを用意して、引数に Dateを受け取り、名前のリストを戻
す
- ユースケースのレイヤーで
SQLは使用しない
- その代わり、ゲートウェイにメソッドを用意して使う
- ゲートウェイはDBのレイヤーにあるクラスで実装する
- この実装もSQLを使うのでHumble Objectである
- インタラクターはビジネスルールをカプセル化しているので、テスト可能

15. 第二章：データマッパー
- ORM(Object Relational Mapping)
- 書籍ではORMは存在しないと書かれている
- ORMはどのレイヤーかというと、
DBである
- このように、境界の近くには
Humble Objectパターンが存在する

16. 第Ⅴ部：Part4 まとめ
- クリーンアーキテクチャ
- 今まで様々なアーキテクチャが存在した
- 依存性は、より上位レベルの方針にのみ向けよ (一方方向)
- 制御の流れと依存方向は分離し制御せよ
- プレゼンターとHumble Object
- Humble Objectとはデザインパターンの 1つである
- テストしにくい振る舞いと、テストしやすい振る舞いを分離する
- 境界の近くに存在する