公式からひも解く Go のディレクトリ構成

はじめに

Go で開発するにあたって、適切なディレクトリ構成を組むことで以下のようなメリットが得られます。

• 開発効率の向上
• コードの整理
• 保守性の向上

Go では公式でディレクトリ構成のガイドを公開しています。
https://go.dev/doc/modules/layout

本記事ではこちらのガイドを要約し、初学者でも分かりやすいように解説することを目的とします。
要約記事は以下にありますので、英語がつらい方はこちらもご参照ください。

https://zenn.dev/furon/articles/2fad1ba7a82171

なお、公式ガイドが公開される前は以下の非公式ガイドがよく参考にされていました。
本記事ではこちらの解説は行いませんが、興味のある方はぜひご一読ください。

https://github.com/golang-standards/project-layout

前提条件

Go はバックエンドアプリケーション開発でよく採用される言語です。
Go には以下のような特徴があります。

• 並行処理を行える
• 学習コストが比較的低い
• 高速処理が可能
• 文法がシンプルなため、開発者による表記の揺れが少ない
• おまじない（ブラックボックス化された仕様）が少ない
• （現段階では）後方互換性が保証されている

システム要件や開発者のスキルセットによっては別言語の方が優れていることもありますが、
現状バックエンド開発にあたって、Go はまず採用を検討すべき言語と言えるでしょう。

今回は Go をバックエンド開発に用いた場合を想定して、そのディレクトリ構成について検討していきます。

ディレクトリ構成

project-root-directory/
  go.mod
  internal/
    auth/
      ...
    metrics/
      ...
    model/
      ...
  cmd/
    api-server/
      main.go
    metrics-analyzer/
      main.go
    ...
  ... その他、Go 以外のコードを格納するディレクトリ

go.mod

Go では様々なパッケージを利用します。利用時には特定のバージョンを指定します。
モジュールとはパッケージとバージョンの依存関係を管理するもので、go.mod というファイルで管理されます。

go.mod は 1 つのプロジェクトで複数配置することも可能です。
今回のユースケースでは go.mod はプロジェクトルート直下に配置して一元管理します。

internal

基本的にバックエンドとして Go を採用する場合、パッケージを外部公開する必要はありません。
その場合、internal ディレクトリ配下にプログラムを配置することで外部アクセスを防ぐことができます。
internal ディレクトリではビジネスロジックを含む様々なディレクトリを構成できます。
例えば、認証に関わる auth ディレクトリや、メトリクス情報を取得する metrics ディレクトリ等です。

cmd

アプリケーションのエントリーポイントを記述したプログラムは cmd ディレクトリに配置します。
複数のアプリケーションを動作させる場合はサブディレクトリを作成します。

おわりに

ここまでが Go 公式で述べられている標準のディレクトリ構成となります。
これ以外にも pkg や tests など分割を検討してもいいディレクトリはありますが、以下のやりとりにもある通り Go はディレクトリ構成を強制するものではありません。
システム要件や開発チームによって適切なディレクトリ構成が変わってくるので、単一の指針を示すこと自体ナンセンスなんだという指摘だと私は解釈しています。

https://github.com/golang-standards/project-layout/issues/117