Goのパッケージ構成の失敗遍歴と現状確認

GoでAPIを書くときの問題

最適なパッケージ構成とは

第1ケース: プロジェクトルートに展開する

.
├── db.go
├── errors.go
├── handler.go
├── main.go
└── model.go

第2ケース: MVC

.
├── main.go
├── clients
├── config
├── controllers
├── models
└── views
.
├── article
└── user

第3ケース: MVCにこだわらないレイヤー化(失敗)

.
├── config
├── domain
│ ├── fetcher
│ ├── parser
│ └── worker
├── main.go
└── repository
├── configuration
├── fetcher
└── repository.go

第4ケース: DDDライクなレイヤー化を求めて(再度失敗)

.
├── config
├── domain
│ ├── auth
│ └── streaming
├── handler
│ ├── auth
│ └── streaming
├── main.go
├── middleware
├── repository
│ ├── auth
│ └── streaming
└── vendor

第5ケース: DDDライクなライトなパッケージ構成

.
├── application
│ ├── auth.go
│ ├── auth_test.go
│ ├── setting.go
│ ├── streaming.go
│ └── streaming_test.go
├── config
│ └── auth.go
├── domain
│ ├── authenticator.go
│ ├── entity
│ ├── error.go
│ ├── language.go
│ ├── repository
│ ├── service
│ └── tokenizer.go
├── infrastructure
│ ├── authenticator.go
│ ├── persistence
│ └── token.go
├── interfaces
│ ├── auth
│ ├── customhandler.go
│ ├── errors.go
│ ├── middleware
│ ├── profiler
│ ├── renderer.go
│ ├── settings
│ ├── streaming
│ └── validator.go
└── library
└── datastore.go
  • ユーザーが見つからない時のエラーハンドリングはapplicationinfrastructureのどっちが担うのか
  • libraryに共通処理を切り出す基準
  • interfacesがハンドラとして少し大きいのではないか

終わりに

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store