Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GolangらしいPackage構成を考える/thinking about Golang-li...

inosy22
October 24, 2019

GolangらしいPackage構成を考える/thinking about Golang-like package architecture

DesignOneGo#6 のLT発表資料です
Webアプリケーション設計からGolangらしいPackage構成を考えたものです。
CleanArchitectureを参考に考えた独自設計を元に

- レイヤーでのPackage構成
- レイヤー×Re-ducks思想を織り交ぜたPackage構成

について考察しています。

P.S. 簡易的に作成したものなので、
今後この内容を詳しくした設計サンプル資料を作成したい...!

inosy22

October 24, 2019
Tweet

More Decks by inosy22

Other Decks in Programming

Transcript

  1. レイヤー構成 ( 不採用になった) ※色々省略してる ├── adapter │ ├── controller │

    │ └── user.go │ ├── gateway │ │ └── mysql │ │ └── user.go │ └── presenter │ └── json │ └── user.go ├── application │ ├── output │ │ └── user.go\ (interface) │ ├── repository │ │ └── user.go\ (interface) │ └── usecase │ └── user.go └── domain └── user └── entity.go 12
  2. レイヤー×Re-ducks 構成 ( 採用中) app / infra / domain グループの中に機能毎のPackage

    Package の中は役割の名前でファイルを作る ├── app │ └── user │ ├── controller.go │ ├── output.go\ (interface) │ ├── presenter_json.go │ └── usecase.go ├── domain │ └── user │ └── entity.go └── infra └── user ├── datasource_mysql.go\ (gateway) └── repository.go\ (interface) 18
  3. レイヤー×Re-ducks 構成のメリデメ メリット レイヤー構成のデメリットは大体解消できる Package 内部に閉じ込められる部分が多くなるの で、Private な部分が妥協実装も許容しやすい ( なんかGolang

    を活かしたPackage 構成っぽい) デメリット レイヤー違いで同Package にあるので、メンバー アクセスが縛りづらくなる import で名前が被るためalias をつける必要あり 19