CleanArchitecture 23章&24章 Sasaki 

23章　プレゼンターとHumble Object プレゼンターはHumbleObjectパターンの一つであり、アーキテクチャの教会の特定と保 護に役立つものです。 

HumbleObjectパターン HumbleObjectパターン‥UTしにくい振る舞いとしやすい振る舞いを分離するために生 み出されたデザインパターン Humble‥意味：控えめ。テストが難しい振る舞い。 HubmleObjectから取り除かれたテスト‥テストしやすい振る舞い。 

プレゼンターとビュー View‥HumbleObjectパターン。→コードをシンプルに保っておく必要がある。 ViewModelからデータを読み込み画面に移動させる以外仕事がない。 Presenter‥テスト可能なオブジェクト。アプリからデータを受け取りViewに適切なオブ ジェクトを送る役割がある。表示させたいデータはViewModelに配置する。 

テストとアーキテクチャ 境界の定義　＝　テストしやすい部分　｜　しにくい部分が分かれている ここではPresenterとViewもそうした境界で分かれている 

データベースゲートウェイ ● DBに対して実行する作成・読み取り・更新・削除全てのメソッドを含んだポリモー フィックインターフェイス。 ● データベースのレイヤーのあるクラスで実装する。（HumbleObjectである） インタラクター ● ビジネスルールを含んでいる。 ● Humbleではない。テスト可能。 ● ゲートウェイをスタブなどに書き換えることができるため。 

データマッパー Q.HibernateのようなORMはどのレイヤー？ A.データベースのレイヤー データ構造はユーザーの観点から見えない。ORMは振る舞いを持たないデータの集合 体であるため「データマッパー」と呼ぶ方が適切。 RDBから取ったデータをデータ構造に当てはめる。 結論：ORMはゲートウェイインターフェイスとデータベースの間にHumbleObjectの境界 を作るものである。 

サービスリスナー アプリが他のサービスと通信を行う、アプリがサービスを提供する場合にHumbleObject パターンがサービスの境界を作成する。 インターフェイス→リスナー→データをフォーマット→サービス境界を超えて→アプリに データ構造を戻す。 

23章のまとめ アーキテクチャの境界にはHumbleObjectパターンが潜んでいる。 境界にはテストしやすい・しにくい部分に分割する。 ↑うまく利用するとシステム全体のテスト容易性が大幅に向上する。 

24章　部分的な境界 悩み：本格的なアーキテクチャの境界はコストが高い 解決策：確かに違反している。だがあとで必要になることもある。と考える。 →部分的な境界を実装する。（あとで必要になるかもって部分のことだと思う） 〜アジャイルコミュニティの言葉〜 　　You Aren’t Going to Neet Id. (YAGNI) 

最後のステップを省略する 部分的な境界の構築方法：独立してコンパイルやデプロイが可能なコンポーネントを準 備→それらを同じコンポーネントにまとめる。 FitNesseの例 ユーザーが他のjarを探したりバージョンの互換性を気にすることなく一つのjarをダウン ロードするだけで実行できるようにした。 危険性：時間だたつとウェブコンポーネントが必要なくなってきた。そしたらウェブとWiki の分離が弱くなり、今では両者を再度分離することが面倒になってきた。 

片方だけの境界 Strategyパターン‥将来のアーキテクチャの境界の準備。 ClientからはServiceBoundaryインターフェイスを使用し、 ServiceImplに実装されている。 目的：クライアントをServiceImpl から分離するため。 

Facade クライアントからアクセスできないクラスにサービス呼び出しを行う。 ただしClientは全てのサービスくらすに依存しており、Serviceのコードを変更するたびに Clieantの再コンパイルも必要になる。。。 

まとめ 24章で紹介した部分的な境界は最終的に完全な境界に至るまでの代理として特定の状 況では適切である。 アーキテクチャの境界をいつどこに作るのか、それは完全な境界なのか部分的な境界な のかを決めるのはアーキテクトの役割である。