UseCaseの凝集度を高める Goのpackage戦略 / Go packaging strategy to increase use case cohesion

by Tomoki Tamura

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© ZOZO, Inc. 4 ショップスタッフの販売サポートツール「FAANS」とは ● WEAR, ZOZOTOWN, Yahoo!ショッピング, ブランド様の自社ECへのコーディネート投稿や成果の確認など、ショップスタッフの運用に必要な機能を搭載した業務支援ツール ● お客様がZOZOTOWN上でブランド実店舗の在庫取り置きを希望した際に、ショップスタッフが FAANS上での簡単操作で取り置き対応を完結できる機能など存在 ● FAANSバックエンドでは、APIの実装をGo言語で開発

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 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はメソッドごとに定義している

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 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 } 依存が増える場合がある（既存の改修により増える場合も）新規メソッドが追加

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© ZOZO, Inc. 13 試しに改善: 1UseCase1メソッドにする type ShopGetUseCase interface { Get(context.Context, *ShopGetInput) (*ShopOutput, error) } type shopGetUseCase struct { aRepo repository.AReopsitory } ● 無駄な依存が一切なくなり、最低限な依存のみとなり、変更による影響が最小化される ● テスト書く際には、モックすべきレポジトリが一目瞭然となり書きやすい

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© ZOZO, Inc. 16 似たような命名のstructがあり、見通しが悪い 1/2 type ShopUpdateInput struct { Name string } type ShopDeleteInput struct { Name string } ... ● ControllerからUseCaseを呼び出す際に利用する、 DTOのInputをUseCase（メソッドごと）に作成しているので、どんどん見通しが悪くなるし、命名が被ることも考慮する必要がある

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 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と命名

Slide 26

Slide 26 text

© 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する」だと煩雑に見える

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© ZOZO, Inc. 28 実際の実装（関数命名）4/5 // usecase/shop/create/usecase.go func convertShopModelToOutput(m shopModel) Output { return Output{} } ● 関数もconvertShopModelToOutputとしても、他ユースケースと関数名が被ることはなくなるので、気にすることが減った

Slide 29

Slide 29 text

© 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で分かりやすい

Slide 30

Slide 30 text

© ZOZO, Inc. 30 package戦略の効果 ● １つのユースケースを実行する独立した UseCaseモジュールとなり、凝集度が高くなり、責務や関心事が一箇所にまとまった ● 命名がシンプルになった ○ ShopCreateInput → Input とだけ命名で済むようになった ○ 被らないように関数名をどうするか？に対して考える必要がほとんど無くなった ● 既存の実装の書き方と大きく変わらなかったため軽量に変更できるし、コスト対効果が大きかった

Slide 31

Slide 31 text

© ZOZO, Inc. 31 実際細かく分割を試してみて思ったこと pros ● pros: packageが分割されているので責務が分かり易くなった ● pros: usecaseに何気なく置いていた共通処理は、本当に usecaseで良かったのかと考える機会が増えた ○ 細かくpackage分割されたことにより、複数 usecaseで利用するような共通処理は、とりあえず usecaseに書いておくみたいなことが気軽にできなくなった。それにより、本当は usecaseではなく別のところに書くべきだと気づきを得ることがある ● pros: packageを分割により、関数名など命名に迷いがなくなった ○ 前はShopUseCase, ShopCreateInputとかで、場合よってはもっと長い命名だったのでシンプル

Slide 32

Slide 32 text

© ZOZO, Inc. 32 実際細かく分割を試してみて思ったこと cons ● cons: エイリアスをつけてimportしないと分かりづらいので、それは面倒だった ○ 前はエイリアス付けず、usecase.ShopUseCaseのようにアクセスできていた ● cons: 命名は確かにシンプルになったが、そのためとはいえ分割しすぎたかも？っと感じた ○ usecase/shop/までで十分で、usecase/shop/get.goが正しい分割だったかもしれないと感じてきた ○ usecase/shop/まで切ったとしても多くても10ユースケースが含まれるかどうかなので、命名の衝突はほぼ無さそうだし、shopUseCaseの関心事として十分わかりやすい構成だなと思った ○ usecaseが巨大になってしまったのは、正しく分割できていなかったことが原因であり、モジュラモノリスを採用してshop, companyのような粒度で垂直分割してたら、それぞれが巨大になることはなさそうだし、綺麗に分割できていたと思う ○ 今後モジュラモノリスを採用するとなった場合にも、 usecase/shop/までの分割だったらそのまま移行しやすそうだなと感じた

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 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

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 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をまとめる

Slide 39

Slide 39 text

© 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をまとめる