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
クリーンアーキテクチャ をGoでする場合に不要な Interfaceは消しやがれ
Search
garebare
June 17, 2022
Programming
0
120
クリーンアーキテクチャ をGoでする場合に不要な Interfaceは消しやがれ
6月17日に行われたNEWDEBUG!!!!で発表した史料です。
https://caspur.wintu.dev/front/lives/264
garebare
June 17, 2022
Tweet
Share
More Decks by garebare
See All by garebare
ペンギンをおすすめする
garebareda
0
34
hey-techcamp-2022
garebareda
2
62
Rustで作った自作コマンド群の話
garebareda
0
160
自作Git作った話
garebareda
3
690
Rustで自作言語のインタプリタ作って Webで動くようにした話
garebareda
0
790
Vtuberをやりたくなりました
garebareda
1
74
Other Decks in Programming
See All in Programming
漸進。
ssssota
0
1.7k
SODA - FACT BOOK
sodainc
1
700
Zennの運営完全に理解した #完全に理解したTalk
wadayusuke
1
180
FastMCPでMCPサーバー/クライアントを構築してみる
ttnyt8701
2
130
単体テストの始め方/作り方
toms74209200
0
410
#QiitaBash TDDでAIに設計イメージを伝える
ryosukedtomita
2
1.7k
人には人それぞれのサービス層がある
shimabox
3
660
ワンバイナリWebサービスのススメ
mackee
10
7.7k
RubyKaigiで得られる10の価値 〜Ruby話を聞くことだけが RubyKaigiじゃない〜
tomohiko9090
0
130
Julia という言語について (FP in Julia « SIDE: F ») for 関数型まつり2025
antimon2
3
890
try-catchを使わないエラーハンドリング!? PHPでResult型の考え方を取り入れてみよう
kajitack
3
480
生成AIで日々のエラー調査を進めたい
yuyaabo
0
480
Featured
See All Featured
Designing for Performance
lara
609
69k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
Site-Speed That Sticks
csswizardry
10
620
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Building an army of robots
kneath
306
45k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Unsuck your backbone
ammeep
671
58k
Speed Design
sergeychernyshev
30
990
Automating Front-end Workflow
addyosmani
1370
200k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
52
2.8k
Transcript
クリーンアーキテクチャを Goでする場合に不要な Interfaceは消しやがれ @garebare521
By たふみ神
ということで考えて行こうと思います
クリーンアーキテクチャとは
Entity UseCase Cotroller UI DB
なんかこういうやつ!
Interfaceで依存を逆転させてるらしい
実装例 type Hoge struct { … } type HogeUsecase struct
{ … } type HogeRepository struct { …. } type Hoge Controller struct { … }
実装例 hogeRepo:=NewHogeRepository() hogeUse :=NewHogeUsecase(hogeRepo) hogeCtrl := NewHogeCtroller(hogeUse)
実装例 hogeCtrl.Post () hogeUse.Post () HogeRepo.Insert()
Interfaceなしだと モックが作れないので テストし難い
Interface書くしかない
クリーンアーキテクチャを Goでする場合に不要な Interfaceは消しやがれ
じゃあどうするか
とりあえず実装量が少なそうな UseCase層を取り除く
Entity UseCase Cotroller UI DB
Entity Cotroller UI DB
単純にインターフェースを削除すると テストが破綻する
テストしやすい形にしたい
じゃあもう実態持たせる必要なくない?
Entity UI DB Controller
Entity UI DB Controller こうしたい
実態を持たせずに Interfaceと同じようなことをしたい
関数を引数に渡せばよくね????
関数を渡すようにするとテストも書きやすい
HogeController func (c *hogeCtrl) Post(c Context, insert func(hoge Hoge) (error))
{ insert() } hogeCtrl.Post(c, hogeRepo.insert)
関数の引数をInterface代わりにして 解決!
ただ必要な関数が増えるたびに 引数も増えます