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
81
CleanArchitecture17章&18章
ssknnm
0
210
CleanArchitecture第5章&第6章
ssknnm
0
95
Other Decks in Technology
See All in Technology
Delta airlines®️ USA Contact Numbers: Complete 2025 Support Guide
airtravelguide
0
340
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
330
生成AI時代 文字コードを学ぶ意義を見出せるか?
hrsued
1
810
「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある / 2025.07.01 LLM品質Night
smiyawaki0820
1
500
American airlines ®️ USA Contact Numbers: Complete 2025 Support Guide
airhelpsupport
0
350
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
27k
モバイル界のMCPを考える
naoto33
0
420
開発生産性を測る前にやるべきこと - 組織改善の実践 / Before Measuring Dev Productivity
kaonavi
3
1.2k
面倒な作業はAIにおまかせ。Flutter開発をスマートに効率化
ruideengineer
0
210
OSSのSNSツール「Misskey」をさわってみよう(右下ワイプで私のOSCの20年を振り返ります) / 20250705-osc2025-do
akkiesoft
0
140
整頓のジレンマとの戦い〜Tidy First?で振り返る事業とキャリアの歩み〜/Fighting the tidiness dilemma〜Business and Career Milestones Reflected on in Tidy First?〜
bitkey
2
14k
Operating Operator
shhnjk
1
510
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Balancing Empowerment & Direction
lara
1
420
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Building an army of robots
kneath
306
45k
Music & Morning Musume
bryan
46
6.6k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
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章で紹介した部分的な境界は最終的に完全な境界に至るまでの代理として特定の状 況では適切である。 アーキテクチャの境界をいつどこに作るのか、それは完全な境界なのか部分的な境界な のかを決めるのはアーキテクトの役割である。