Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
UseCaseの凝集度を高める Goのpackage戦略 / Go packaging str...
Search
Tomoki Tamura
September 20, 2023
Programming
3
2.4k
UseCaseの凝集度を高める Goのpackage戦略 / Go packaging strategy to increase use case cohesion
UseCaseの凝集度を高める Goのpackage戦略 / Go packaging strategy to increase use case cohesion
Tomoki Tamura
September 20, 2023
Tweet
Share
Other Decks in Programming
See All in Programming
Seamless Flutter Native Integration: FFI & Pigeon - Dreamwalker (JaichangPark / 박제창) @FlutterKaigi2024
itsmedreamwalker
0
110
React + Tauriでデスクトップアプリ開発に入門してみた
ynishimura0922
0
180
Welcome JSConf.jp 2024
yosuke_furukawa
PRO
0
3k
5分ぐらいで分かる、トリミング機能の作り方
tsutsuitakumi
0
190
CSC305 Lecture 23
javiergs
PRO
0
120
talk-with-local-llm-with-web-streams-api
kbaba1001
0
140
Modular Monolith Monorepo ~シンプルさを保ちながらmonorepoのメリットを最大化する~
yuisakamoto
11
3.9k
CSC509 Lecture 13
javiergs
PRO
0
150
物流システムにおけるリファクタリングとアーキテクチャの再構築 〜依存関係とモジュール分割の重要性〜
deeprain
1
430
我々のデザインシステムは Chakra v3 にアップデートします
shunya078
2
2.9k
macOS なしで iOS アプリを開発する(※ただし xxx に限る)
mitsuharu
1
170
Vue.js_好きに捧ぐ Nuxt Hub で簡単に始めるCloudflare
xiombatsg
1
120
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
789
250k
A Philosophy of Restraint
colly
203
16k
Building an army of robots
kneath
302
43k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
A better future with KSS
kneath
238
17k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Gamification - CAS2011
davidbonilla
80
5.1k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
480
Transcript
UseCaseの凝集度を高める Goのpackage戦略 2023年09月20日 株式会社ZOZO ブランドソリューション開発本部 バックエンド部 FAANSバックエンドブロック 田村 誠基 Copyright ©
ZOZO, Inc. 1
© ZOZO, Inc. 株式会社ZOZO ブランドソリューション開発本部 バックエンド部 FAANSバックエンドブ ロック 田村
誠基 2020年4月 入社 自社ECの運用保守業務に従事し、その後FAANSのバックエンド エンジニアとしてAPI開発をしています。 好きなエディタは、Neovimです! 最近、M2 ProのMacBookに変え、PCが爆速になった。 2
© ZOZO, Inc. 3 Agenda • ショップスタッフの販売サポートツール「 FAANS」とは • UseCaseの変更前実装
• 解決のアプローチ • DIツール wire の紹介 • まとめ
© ZOZO, Inc. 4 ショップスタッフの販売サポートツール「FAANS」とは • WEAR, ZOZOTOWN, Yahoo!ショッピング, ブランド様の自社ECへのコーディネート投稿や成果の確認
など、ショップスタッフの運用に必要な機能を搭載した業務支援ツール • お客様がZOZOTOWN上でブランド実店舗の在庫取り置きを希望した際に、ショップスタッフが FAANS上 での簡単操作で取り置き対応を完結できる機能など存在 • FAANSバックエンドでは、APIの実装をGo言語で開発
© ZOZO, Inc. 5 クリーンアーキテクチャを採用している • 今回は、UseCase部分の実装のお話 「Cloud FirestoreからPostgreSQLへ移行したお話」
© ZOZO, Inc. UseCaseの変更前実装 〜 ディレクトリ構成 〜 6
© ZOZO, Inc. 7 UseCaseディレクトリ構成 • usecaseディレクトリ直下にファイルを置いている ◦ 例: usecase/shop.go
• usecaseディレクトリには90ファイル近く存在していて巨大 └── usecase ├── aa.go ├── bb.go ├── cc.go └── shop.go
© ZOZO, Inc. UseCaseの変更前実装① 〜 1UseCaseに複数メソッドあることで、依存関係が増えている 〜 8
© ZOZO, Inc. 9 1UseCaseに複数メソッド持っている 1/2 type ShopUseCase interface {
Create(context.Context, *ShopCreateInput) (*ShopOutput, error) Get(context.Context, *ShopGetInput) (*ShopOutput, error) Update(context.Context, *ShopUpdateInput) (*ShopOutput, error) Delete(context.Context, *ShopDeleteInput) (error) } type shopUseCase struct { aRepo repository.AReopsitory bRepo repository.BRepository cRepo repository.CRepository } • ShopユースケースにCreate, Getのように複数メソッドを持たせている • 必要なデータを受け渡しを行う dtoのInputはメソッドごとに定義している
© ZOZO, Inc. 10 1UseCaseに複数メソッド持っている 1/2 • この実装でのメリットは、ユースケースを追加する場合は、メソッドを生やすだけで可能とい うことで、サクッと実装することができる •
短期的に見るとそれで良いかもしれないが、中長期的に見ると依存関係が分かりづらくなって いきメンテナンス性が悪くなる
© ZOZO, Inc. 11 1UseCaseに複数メソッドあることで、依存関係が増加 1/2 type ShopUseCase interface {
Create(context.Context, *ShopCreateInput) (*ShopCreateOutput, error) Get(context.Context, *ShopGetInput) (*ShopGetOutput, error) Update(context.Context, *ShopUpdateInput) (*ShopUpdateOutput, error) Delete(context.Context, *ShopDeleteInput) (error) BulkCreate(context.Context, *ShopBulkCreateInput) ([]*ShopOutput, error) } type shopUseCase struct { aRepo repository.AReopsitory bRepo repository.BRepository cRepo repository.CRepository dRepo repository.DRepository } 依存が増える場合がある (既存の改修により増える場合も) 新規メソッドが追加
© ZOZO, Inc. 12 1UseCaseに複数メソッドあることで、依存関係が増加 2/2 • UseCaseに1メソッド追加されるごとに、依存関係が増える可能性がある ◦ ユースケースが大きくなればなるほど、最大公約数的に増えてしまう
• それにより、テストコードを書く際にモックすべきクラスがどれか分からなくなってくる ◦ テストコード書くのが大変になり面倒になる
© ZOZO, Inc. 13 試しに改善: 1UseCase1メソッドにする type ShopGetUseCase interface {
Get(context.Context, *ShopGetInput) (*ShopOutput, error) } type shopGetUseCase struct { aRepo repository.AReopsitory } • 無駄な依存が一切なくなり、最低限な依存のみとなり、変更による影響が最小化される • テスト書く際には、モックすべきレポジトリが一目瞭然となり書きやすい
© ZOZO, Inc. 14 「1UseCase複数メソッド」と「1UseCase1メソッド」 • 依存が最小限となっており、 1UseCase1メソッドの方が分かりやすい
© ZOZO, Inc. UseCaseの変更前実装② 15 〜 似たような命名のstructがあり、見通しが悪い 〜
© ZOZO, Inc. 16 似たような命名のstructがあり、見通しが悪い 1/2 type ShopUpdateInput struct {
Name string } type ShopDeleteInput struct { Name string } ... • ControllerからUseCaseを呼び出す際に利用する、 DTOのInputをUseCase(メソッドごと)に作成してい るので、どんどん見通しが悪くなるし、命名が被ることも考慮する必要がある
© ZOZO, Inc. 17 似たような命名のstructがあり、見通しが悪い 2/2 func convertShopModelToShopOutput(m shopModel) ShopOutput
{ return ShopOutput{} } • 他にもDTO変換処理をusecaseパッケージ内に記載しているので、被らないようにするために名前が煩 雑になっている
© ZOZO, Inc. これらの実装を整理すると 18
© ZOZO, Inc. 19 凝集度が低いと感じる • 1ユースケースに複数メソッドあることで、依存関係が増えて、変更に弱いユースケースになっている • UseCaseというパッケージが大きくて修正しづらい場面がある ◦
DTOのInputや変換処理などの命名が被らないように気を付ける必要がある
© ZOZO, Inc. 解決のアプローチ 20
© ZOZO, Inc. 21 解決の方針 • 1UseCase1メソッドにして依存関係を最小限にしたい • Inputや関数などの見通しの悪さや命名の煩わしさから解放されたい •
開発案件も進める必要もあり、現状の実装を大きく変えずに、軽量に実施できる方法にしたい
© ZOZO, Inc. 22 パッケージ分割のアプローチ • createShop、getShopなどは、完全に独立した実装が可能 • 命名の煩わしさをなくすために、思い切って usecase/shop/create/usecase.goのようにパッケージを分割
• Goのお作法的には細かく切らない方が良いと思うが、 FAANS においてはこの方針の方が開発しやすいのではということで新 規APIに関しては、模索しつつお試し実装をしてみた └── usecase ├── company │ └── list │ └── usecase.go └── shop ├── create │ └── usecase.go ├── delete │ └── usecase.go ├── get │ └── usecase.go └── update └── usecase.go
© ZOZO, Inc. 23 パッケージの命名について • パッケージの切り方の命名 • 基本的には、usecase/{ドメインモデル名}/{操作名}/usecase.goのルール •
迷ったら都度相談 ◦ Create → create ◦ Read → get ◦ Update → update ◦ Delete → delete ◦ リスト取得 → list
© ZOZO, Inc. 新しい方針の実装 24
© ZOZO, Inc. 25 実際の実装 1/5 // usecase/shop/create/usecase.go type UseCase
interface { Run(context.Context, *Input) (*Output, error) } type usecase struct { aRepo repository.AReopsitory } type Input struct { Name string } 一律UseCaseと命名 呼び出しメソッドはRunで統一 必要な依存のみ 一律Inputと命名
© ZOZO, Inc. 26 実際の実装(usecase)2/5 // usecase/shop/create/usecase.go type UseCase interface
{ Run(context.Context, *Input) (*Output, error) } • usecaseからの分割で、shopのcreateのUseCaseだと分かる ◦ UseCaseの命名で問題ない • 1ユースケース1メソッドなので、Runで問題ない ◦ 呼び出し側は「shop作成のユースケースを Runする」で扱いやすい ◦ 「shop作成のユースケースを Createする」だと煩雑に見える
© ZOZO, Inc. 27 実際の実装(input命名)3/5 // usecase/shop/create/usecase.go type Input struct
{ Name string } • ユースケースごとにパッケージが閉じているので、 Inputの命名で問題ない
© ZOZO, Inc. 28 実際の実装(関数命名)4/5 // usecase/shop/create/usecase.go func convertShopModelToOutput(m shopModel)
Output { return Output{} } • 関数もconvertShopModelToOutputとしても、他ユースケースと関数名が被ることはなくなるので、気に す ることが減った
© ZOZO, Inc. 29 実際の実装(controllerからの呼び出し)5/5 import ( createShopUseCase "hoge/usecase/shop/create" )
func (c *ShopController) Create(...) { shop, err := c.createShopUseCase.Run(ctx, createShopUseCase.Input{}) } • 呼び出す際には、どの UseCaseの操作かを把握しやすいように package名にエイリアスをつける • createShopUseCase.Input, createShopUseCase.Outputのようにアクセス可能 ◦ パッケージが別れていることにより、 .Input, .Ouputで分かりやすい
© ZOZO, Inc. 30 package戦略の効果 • 1つのユースケースを実行する独立した UseCaseモジュールとなり、凝集度が高くなり、責務や関心事が 一箇所にまとまった •
命名がシンプルになった ◦ ShopCreateInput → Input とだけ命名で済むようになった ◦ 被らないように関数名をどうするか?に対して考える必要がほとんど無くなった • 既存の実装の書き方と大きく変わらなかったため軽量に変更できるし、コスト対効果が大きかった
© ZOZO, Inc. 31 実際細かく分割を試してみて思ったこと pros • pros: packageが分割されているので責務が分かり易くなった •
pros: usecaseに何気なく置いていた共通処理は、本当に usecaseで良かったのかと考える機会が増えた ◦ 細かくpackage分割されたことにより、複数 usecaseで利用するような共通処理は、とりあえず usecaseに書いておくみたいなことが気軽にできなくなった。それにより、本当は usecaseではなく別 のところに書くべきだと気づきを得ることがある • pros: packageを分割により、関数名など命名に迷いがなくなった ◦ 前はShopUseCase, ShopCreateInputとかで、場合よってはもっと長い命名だったのでシンプル
© ZOZO, Inc. 32 実際細かく分割を試してみて思ったこと cons • cons: エイリアスをつけてimportしないと分かりづらいので、それは面倒だった ◦
前はエイリアス付けず、usecase.ShopUseCaseのようにアクセスできていた • cons: 命名は確かにシンプルになったが、そのためとはいえ分割しすぎたかも?っと感じた ◦ usecase/shop/までで十分で、usecase/shop/get.goが正しい分割だったかもしれないと感じてきた ◦ usecase/shop/まで切ったとしても多くても10ユースケースが含まれるかどうかなので、命名の衝突はほぼ無 さそうだし、shopUseCaseの関心事として十分わかりやすい構成だなと思った ◦ usecaseが巨大になってしまったのは、正しく分割できていなかったことが原因であり、モジュラモノリスを採用 してshop, companyのような粒度で垂直分割してたら、それぞれが巨大になることはなさそうだし、綺麗に分割 できていたと思う ◦ 今後モジュラモノリスを採用するとなった場合にも、 usecase/shop/までの分割だったらそのまま移行しやすそ うだなと感じた
© ZOZO, Inc. 33 今後について • 前の実装からは、問題点も解決されて良くなって、開発し易くなった • しかし、この分割の粒度が本当に正しかったかどうかは、自分の中でも答えは出ていないので、今一度検 討したいところではある
© ZOZO, Inc. DIツール wire の紹介 34
© ZOZO, Inc. 35 DIツール wire • FAANSでは、DIツールのwireを利用 • 今回の修正でpackageが細かく分割されることにより、
DI関連のコードが冗長にならないようにしたい • providerがどこに存在するかを把握しやすくするため、 packageごとにprovidorグループを作成することで 意識することを減らせる
© ZOZO, Inc. 36 DIツール wire ファイル構成 1/5 • packageごとにproviderグループを作るために、それぞれ
wire.goを持つようにしている └── usecase ├── shop │ ├── create │ │ ├── usecase.go │ │ └── wire.go │ ├── get │ │ ├── usecase.go │ │ └── wire.go │ └── wire.go └── wire.go
© ZOZO, Inc. 37 DIツール wire 2/5 // usecase/shop/create/wire.go var
WireSet = wire.NewSet( NewUsecase, ) • それぞれのpackageでproviderグループを作成
© ZOZO, Inc. 38 DIツール wire 3/5 // usecase/shop/wire.go import
( "github.com/google/wire" "hoge/usecase/shop/create" "hoge/usecase/shop/get" ) var WireSet = wire.NewSet( create.WireSet, get.WireSet, ) サブモジュールのWireSetをまとめる
© ZOZO, Inc. 39 DIツール wire 4/5 // usecase/wire.go import
( "github.com/google/wire" "hoge/usecase/company" "hoge/usecase/shop" ) var WireSet = wire.NewSet( company.WireSet, shop.WireSet, ) サブモジュールのWireSetをまとめる
© ZOZO, Inc. 40 DIツール wire 5/5 wire.Build( controller.NewShopController, usecase.WireSet,
) • injector側で、usecase.WireSet指定することで、DIしてくれる • これにより、packageが細かく分割されたとしても usecaseのWireSetだけ意識するだけで済むようになる
© ZOZO, Inc. まとめ 41
© ZOZO, Inc. 42 まとめ • UseCaseの凝集度を高め開発し易くするために、細かくパッケージ分割を行って問題点は解決された • 試してみてよかったところもあれば、気になるところも出てきた •
それを踏まえて今後どういう構成が良いか考え、より開発しやすい構成を模索していく
None