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

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

どんな仕事しているか GameWith のリプレイスプロジェクトチーム 「Incremental Stream 」のスクラムマスターとして プロジェクトの計画管理や設計・開発を担当してます その中でGolang を利用した時の話になります どんなプロジェクトチームなのかは本日 (2019/10/24) 公開のブログに記載しています！ blog:GameWith のリプレイスについて vol.1 ~ 概要編~ 3

～本日の概要～ Web アプリケーション設計から Golang らしいPackage 構成を考える 4

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

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

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

CleanArchitecture の図 引用：The Clean Architecture 8

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

具体的なPackage 構成を考える レイヤー構成 ( 不採用になった) レイヤー×Re-ducks 構成 ( 採用中) 10

CleanArchitecture を参考にした設計 11

レイヤー構成 ( 不採用になった) ※色々省略してる ├── 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

レイヤー構成のメリデメ メリット レイヤーでPackage が別れているので、import で 依存関係やメンバーアクセスのルールが縛れる デメリット 機能が増えるにつれてレイヤーPackage が肥大化 レイヤー内で他の機能に自由にアクセスが可能 (IDE の補完のサジェストの肥大化) 機能の実装時にディレクトリの行き来が激しく てとにかく辛い... 。 13

レイヤー構成の考察 おそらく一般的にGolang×CleanArchitecture でネッ トで調べると一番出てくるPackage 構成が、このレイ ヤー構成。 小さいプロジェクトでレイヤー内の肥大化が発生しな いようなものの時には有効な構成だと思われる。 でも、なんだかGolang のPackagePrivate の仕組みな どを活かしきれていないような... ？ → React×Redux をやっていた時代に採用していた、 Re-ducks 構成を織り交ぜたらどうだろうか... ？ 14

Re-ducks 構成とは 参考：https://github.com/alexnm/re-ducks こちらはレイヤー( 役割) でディレクトリを切る形では なく、機能でディレクトリを分けた上で、ファイル名 に役割名をつける構成。 15

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

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

レイヤー×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

レイヤー×Re-ducks 構成のメリデメ メリット レイヤー構成のデメリットは大体解消できる Package 内部に閉じ込められる部分が多くなるの で、Private な部分が妥協実装も許容しやすい ( なんかGolang を活かしたPackage 構成っぽい) デメリット レイヤー違いで同Package にあるので、メンバー アクセスが縛りづらくなる import で名前が被るためalias をつける必要あり 19

～結論～ レイヤーにとらわれない Package 構成で幸せになった & (Golang らしいPackage 構成になってそう?) 20

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