Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CleanArchitecture23章&24章
Search
ssknnm
November 18, 2020
Technology
0
280
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
89
CleanArchitecture17章&18章
ssknnm
0
210
CleanArchitecture第5章&第6章
ssknnm
0
100
Other Decks in Technology
See All in Technology
re:Invent 2025 ふりかえり 生成AI版
takaakikakei
1
210
Database イノベーショントークを振り返る/reinvent-2025-database-innovation-talk-recap
emiki
0
180
Snowflakeでデータ基盤を もう一度作り直すなら / rebuilding-data-platform-with-snowflake
pei0804
6
1.6k
チーリンについて
hirotomotaguchi
6
2k
因果AIへの招待
sshimizu2006
0
980
寫了幾年 Code,然後呢?軟體工程師必須重新認識的 DevOps
cheng_wei_chen
1
1.4k
Gemini でコードレビュー知見を見える化
zozotech
PRO
1
260
[CMU-DB-2025FALL] Apache Fluss - A Streaming Storage for Real-Time Lakehouse
jark
0
120
Sansanが実践する Platform EngineeringとSREの協創
sansantech
PRO
2
870
Oracle Cloud Infrastructure IaaS 新機能アップデート 2025/09 - 2025/11
oracle4engineer
PRO
0
140
Reinforcement Fine-tuning 基礎〜実践まで
ch6noota
0
190
生成AIでテスト設計はどこまでできる? 「テスト粒度」を操るテーラリング術
shota_kusaba
0
780
Featured
See All Featured
Site-Speed That Sticks
csswizardry
13
1k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
Documentation Writing (for coders)
carmenintech
76
5.2k
Navigating Team Friction
lara
191
16k
Designing for humans not robots
tammielis
254
26k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.1k
Leading Effective Engineering Teams in the AI Era
addyosmani
8
1.3k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Six Lessons from altMBA
skipperchong
29
4.1k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
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章で紹介した部分的な境界は最終的に完全な境界に至るまでの代理として特定の状 況では適切である。 アーキテクチャの境界をいつどこに作るのか、それは完全な境界なのか部分的な境界な のかを決めるのはアーキテクトの役割である。