Pro Yearly is on sale from $80 to $50! »

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

6979e2d5440dda83d31c68d80503b0f5?s=47 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. 簡易的に作成したものなので、
今後この内容を詳しくした設計サンプル資料を作成したい...!

6979e2d5440dda83d31c68d80503b0f5?s=128

inosy22

October 24, 2019
Tweet

Transcript

  1. Golang らしいpackage 構成を考える by @inosy22 2019/10/24 DesignOneGo#6 LT 用 1

  2. 自己紹介 名前:猪野凌也/ いのす/@inosy22 所属:株式会社GameWith 役割:サーバーサイドエンジニア フロントとインフラもやります 勉強中:Golang/Vue(Nuxt)/C#(Unity) 今まで:Java/C++/PHP/React 好き:アーキテクチャ/ ゲーム/Vtuber

    2
  3. どんな仕事しているか GameWith のリプレイスプロジェクトチーム 「Incremental Stream 」のスクラムマスターとして プロジェクトの計画管理や設計・開発を担当してます その中でGolang を利用した時の話になります どんなプロジェクトチームなのかは本日

    (2019/10/24) 公開のブログに記載しています! blog:GameWith のリプレイスについて vol.1 ~ 概要編~ 3
  4. ~本日の概要~ Web アプリケーション設計から Golang らしいPackage 構成を考える 4

  5. ~前提~ Golang を利用して CleanArchitecture を参考に Web アプリケーションを作成する にあたってのPackage 構成 5

  6. ~注意~ golang-standard/project-layout こちらのようなディレクトリ構成には言及せず、 アプリケーション実装のディレクトリ構成 のみに焦点を置いた話をします 6

  7. CleanArchitecture とは レイヤードアーキテクチャの一つで、 レイヤー間の依存関係を単方向にして、 それぞれのレイヤーを疎結合にできるアーキテクチャ 7

  8. CleanArchitecture の図 引用:The Clean Architecture 8

  9. Golang のPackage 仕様 Package はnamespace のような機能を果たす 名前はスネークケースやキャメルケースはNG ディレクトリ直下のファイルは同じPacakge 裏を返せばディレクトリが違えば別Package ディレクトリ構成とPackage

    構成は同義 同じPackage の変数や関数へのアクセスは無制限 Golang のPrivate はPackage 内Private 9
  10. 具体的なPackage 構成を考える レイヤー構成 ( 不採用になった) レイヤー×Re-ducks 構成 ( 採用中) 10

  11. CleanArchitecture を参考にした設計 11

  12. レイヤー構成 ( 不採用になった) ※色々省略してる ├── 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
  13. レイヤー構成のメリデメ メリット レイヤーでPackage が別れているので、import で 依存関係やメンバーアクセスのルールが縛れる デメリット 機能が増えるにつれてレイヤーPackage が肥大化 レイヤー内で他の機能に自由にアクセスが可能

    (IDE の補完のサジェストの肥大化) 機能の実装時にディレクトリの行き来が激しく てとにかく辛い... 。 13
  14. レイヤー構成の考察 おそらく一般的にGolang×CleanArchitecture でネッ トで調べると一番出てくるPackage 構成が、このレイ ヤー構成。 小さいプロジェクトでレイヤー内の肥大化が発生しな いようなものの時には有効な構成だと思われる。 でも、なんだかGolang のPackagePrivate

    の仕組みな どを活かしきれていないような... ? → React×Redux をやっていた時代に採用していた、 Re-ducks 構成を織り交ぜたらどうだろうか... ? 14
  15. Re-ducks 構成とは 参考:https://github.com/alexnm/re-ducks こちらはレイヤー( 役割) でディレクトリを切る形では なく、機能でディレクトリを分けた上で、ファイル名 に役割名をつける構成。 15

  16. レイヤーの構成とRe-ducks の構成を いい塩梅に織り交ぜてみる 16

  17. Package の縦割りと横割りの塩梅 機能で区切り、再利用性を考えた範囲でグループ化 17

  18. レイヤー×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
  19. レイヤー×Re-ducks 構成のメリデメ メリット レイヤー構成のデメリットは大体解消できる Package 内部に閉じ込められる部分が多くなるの で、Private な部分が妥協実装も許容しやすい ( なんかGolang

    を活かしたPackage 構成っぽい) デメリット レイヤー違いで同Package にあるので、メンバー アクセスが縛りづらくなる import で名前が被るためalias をつける必要あり 19
  20. ~結論~ レイヤーにとらわれない Package 構成で幸せになった & (Golang らしいPackage 構成になってそう?) 20

  21. EOP ありがとうございました P.S. こちらの資料は内容をより詳しくして、 設計サンプルとして公表していきたい... ! 21