第ⅴ部：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やツールで構成されている - 通常このレイヤーにはコードをあまり書かない - 書くとしても次のレイヤーとやりとりするグルーコード
- 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つである - テストしにくい振る舞いと、テストしやすい振る舞いを分離する - 境界の近くに存在する