本記事では、標準的なGoプロジェクトの構成と、それに基づいたベストプラクティスについて解説します。
1. 標準的なプロジェクト構成
Goプロジェクトでは、以下のようなディレクトリ構成を採用するのが一般的です。
project-root/
├── cmd/ # メインアプリケーションのエントリーポイント
│ └── app/
│ └── main.go
├── internal/ # 非公開のパッケージ
│ ├── auth/
│ ├── db/
│ └── handler/
├── pkg/ # 公開パッケージ
│ ├── models/
│ └── utils/
├── api/ # API定義、プロトコルファイルなど
├── web/ # Webアプリケーションの静的ファイル
├── configs/ # 設定ファイル
├── scripts/ # ビルドスクリプトなど
├── test/ # 追加のテストファイル
├── docs/ # ドキュメント
├── go.mod
└── go.sum
この構成を採用することで、コードの役割が明確になり、プロジェクトのスケールアップにも対応しやすくなります。
2. 重要なディレクトリの説明
cmd/
– アプリケーションのメインエントリーポイントを格納します。
– 各実行可能ファイルは独自のディレクトリを持つべきです。
internal/
– プロジェクト内部でのみ使用するプライベートなコードを配置します。
– Goコンパイラによって外部からのインポートが禁止されるため、実装の隠蔽に役立ちます。
pkg/
– 他のプロジェクトでも再利用可能な公開パッケージを配置します。
– 安定したAPIを提供し、慎重に設計する必要があります。
api/
– OpenAPI仕様やgRPCプロトコル定義ファイルを格納します。
web/
– フロントエンドの静的ファイル（HTML、CSS、JavaScriptなど）を配置します。
configs/
– 設定ファイル（YAML、JSON、TOMLなど）を格納します。
scripts/
– デプロイやビルドに使用するスクリプトを配置します。
test/
– ユニットテストとは別に、統合テストやエンドツーエンドテストのスクリプトを配置します。
docs/
– プロジェクトのドキュメントを格納します。
3. ベストプラクティス
パッケージ構造
– 各ディレクトリは単一の責任を持つように設計します。
– パッケージ名は簡潔で意味のあるものにします。
依存関係
– 循環依存を避けるため、適切にモジュールを分離します。
– 依存関係は上位レベルから下位レベルへ向かうべきです。
可視性
– 内部実装は `internal/` パッケージに配置し、外部公開を防ぎます。
– 再利用可能なコードは `pkg/` ディレクトリに配置します。
テスト
– テストファイルは実装ファイルと同じディレクトリに配置し、 `*_test.go` という命名規則を守ります。
– 統合テストやエンドツーエンドテストは `test/` ディレクトリに配置します。
このような構成を採用することで、コードの保守性が向上し、チーム開発がスムーズに進行します。
4. 参考文献
1. Go公式ブログ
2. Go標準ライブラリのソースコード
3. Goプロジェクトレイアウト（非公式）
Goプロジェクトにおける設計の助けになれば幸いです。
