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
それ... リポジトリじゃなくね?~実案件から学ぶアンチパターン~/Learn reposit...
Search
Shunya Yamada
October 23, 2020
Programming
0
1.3k
それ... リポジトリじゃなくね?~実案件から学ぶアンチパターン~/Learn repository pattern from real projects
Shunya Yamada
October 23, 2020
Tweet
Share
Other Decks in Programming
See All in Programming
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
330
Hack Claude Code with Claude Code
choplin
6
2.4k
型で語るカタ
irof
0
590
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
350
Android 16KBページサイズ対応をはじめからていねいに
mine2424
0
240
GPUを計算資源として使おう!
primenumber
1
210
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
240
おやつのお供はお決まりですか?@WWDC25 Recap -Japan-\(region).swift
shingangan
0
140
Flutterで備える!Accessibility Nutrition Labels完全ガイド
yuukiw00w
0
170
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
8.3k
20250708_JAWS_opscdk
takuyay0ne
2
120
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
2
11k
Featured
See All Featured
It's Worth the Effort
3n
185
28k
The Invisible Side of Design
smashingmag
301
51k
The Cult of Friendly URLs
andyhume
79
6.5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
What's in a price? How to price your products and services
michaelherold
246
12k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Fireside Chat
paigeccino
37
3.5k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Producing Creativity
orderedlist
PRO
346
40k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Transcript
それ... リポジトリじゃなくね? ~ 件から ぶアンチパターン~ 2020/10/23
似たような発表をしたのでよければ... 前、 の をしたのでよければ 照してください。 https://www.notion.so/a71be224de42457299befa88c76c86d7
発表のきっかけ なんでこんな発 を
とある Flutter 案件 BLoC パターン + クリーンアーキテクチャ View → Bloc
→ Repository ... と Repository が ⾯ごとに 在 さらに下の で API へのリクエスト等が されている 発 のきっかけ
とある Flutter 案件 BLoC パターン + クリーンアーキテクチャ View → Bloc
→ Repository ... と Repository が ⾯ごとに 在 さらに下の で API へのリクエスト等が されている 発 のきっかけ 何かがおかしい...
とある Flutter 案件 BLoC パターン + クリーンアーキテクチャ View → Bloc
→ Repository ... と Repository が ⾯ごとに 在 さらに下の で API へのリクエスト等が されている 発 のきっかけ
とある Flutter 案件 BLoC パターン + クリーンアーキテクチャ View → Bloc
→ Repository ... と Repository が ⾯ごとに 在 さらに下の で API へのリクエスト等が されている 発 のきっかけ
とある Flutter 案件 BLoC パターン + クリーンアーキテクチャ View → Bloc
→ Repository ... と Repository が ⾯ごとに 在 さらに下の で API へのリクエスト等が されている 発 のきっかけ リポジトリが画面実装に依存?
おかしいと思った理由は? リポジトリが ⾯ に するのがなぜいけないのか
その前に.. アーキテクチャの種類について アーキテクチャには⼤きく けて2 種 あります
二種類のアーキテクチャ アーキテクチャの種 GUI アーキテクチャ システムアーキテクチャ
GUI アーキテクチャについて アーキテクチャの種 MVC 、MVP 、MVVM などが 当 システム 来の
領域( ドメイン) をUI( プレゼンテーション) から き離す。 UI が わる 界より先のことはGUI アーキテクチャは何も⽰していない Model の作り は に指 はない : i O S アプリ パターン
システムアーキテクチャについて アーキテクチャの種 クリーンアーキテクチャのようなレイヤードアーキテクチャが 当 GUI アーキテクチャが っていないドメインの領域をどのようにレイヤーで ドメイン = UI
に しない処理すべて 切り けるべきか、システム 体をどのように すべきか : i O S アプリ パターン
二種類のアーキテクチャ アーキテクチャの種 GUIアーキテクチャ MVC MVP MVVM システムアーキテクチャ クリーンアーキテクチャ
二種類のアーキテクチャ アーキテクチャの種 GUIアーキテクチャ MVC MVP MVVM システムアーキテクチャ クリーンアーキテクチャ リポジトリ
リポジトリはシステムアーキテクチャの領域 よって画面実装に依存すべきではない! と個 的には思っています
実装例 そんなにコードはありません
こんな感じのアプリを想定 API から何かの 事を⼀ で ⽰、 索を⾏う ⼀ ⾯と 索
⾯の2 ⾯ ⼀ ⾯では ての 事を 順で 得 索 ⾯では任 のキーワードで 事を 索 例
こんな感じのアプリを想定 例 UI の処理について える ビジネスロジックは API をコールして「 事 得」「
事 索」を⾏う
まずは良くない例 のプロダクションコードはこんな じでした
まずは良くない例 例
まずは良くない例 例
まずは良くない例 例
良い例 ⾯ に しない例
良い例 例
良い例 例
良い例のメリットなど 例 「 事」に する処理を⼀箇 まとめることができる ⾯ に しないので ⾯が
えてもリポジトリは えない ⾯で再利⽤できる 処理が えてきてリポジトリが⼤きくなってきたら、さらに けられないか⾒ し
まとめ まとめ アーキテクチャは「GUI アーキテクチャ」「システムアーキテクチャ」の2 種 システムアーキテクチャは ⾯に はない リポジトリはシステムアーキテクチャの領域 リポジトリは
⾯ごとにではなく、 単 で作った がいい じになる 上となります