Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CleanArchitecture23章&24章
Search
ssknnm
November 18, 2020
Technology
0
260
CleanArchitecture23章&24章
CleanArchitectureの23章と24章です
ssknnm
November 18, 2020
Tweet
Share
More Decks by ssknnm
See All by ssknnm
CleanArchitecture_31章_32章.pdf
ssknnm
0
80
CleanArchitecture17章&18章
ssknnm
0
210
CleanArchitecture第5章&第6章
ssknnm
0
94
Other Decks in Technology
See All in Technology
2025-06-26 GitHub CopilotとAI駆動開発:実践と導入のリアル
fl_kawachi
1
200
LangSmith×Webhook連携で実現するプロンプトドリブンCI/CD
sergicalsix
1
140
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
290
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
11
4k
データプラットフォーム技術におけるメダリオンアーキテクチャという考え方/DataPlatformWithMedallionArchitecture
smdmts
5
660
本が全く読めなかった過去の自分へ
genshun9
0
660
米国国防総省のDevSecOpsライフサイクルをAWSのセキュリティサービスとOSSで実現
syoshie
2
1.2k
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
5
580
Core Audio tapを使ったリアルタイム音声処理のお話
yuta0306
0
140
Oracle Cloud Infrastructure:2025年6月度サービス・アップデート
oracle4engineer
PRO
2
310
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
290
標準技術と独自システムで作る「つらくない」SaaS アカウント管理 / Effortless SaaS Account Management with Standard Technologies & Custom Systems
yuyatakeyama
3
1.3k
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
The Language of Interfaces
destraynor
158
25k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Balancing Empowerment & Direction
lara
1
390
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
How STYLIGHT went responsive
nonsquared
100
5.6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
680
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
GraphQLとの向き合い方2022年版
quramy
49
14k
Transcript
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章で紹介した部分的な境界は最終的に完全な境界に至るまでの代理として特定の状 況では適切である。 アーキテクチャの境界をいつどこに作るのか、それは完全な境界なのか部分的な境界な のかを決めるのはアーキテクトの役割である。