Goのプロジェクトレイアウト

#Goのプロジェクトレイアウト

ここのGithubの和訳です。私的な備忘録なのでだいぶ意訳です。
Goプロジェクトのディレクトリをどう切ろうかと考える際の参考程度に。
https://github.com/golang-standards/project-layout

ディレクトリ	用途
/cmd	プロジェクトのメインのアプリを配置する. /cmd 配下のディレクトリ名は, 最終的な実行バイナリ名と同じにすると良い(e.g.,/cmd/myapp). そのため /cmd 以下のディレクトリは基本的に package main になる. ここへは沢山のコードを配置すべきではない. もし他のコードやプロジェクトから import される類のコードである場合は /pkg ディレクトリに配置するべきだし, もしコードが再利用不可あるいは再利用されたくない場合は /internal に配置すべき. 一般的に /cmd には /internal や /pkg ディレクトリから import して実行する小さい main 関数が置かれる.
/internal	プライベートなアプリやライブラリ, 他のアプリやライブラリから import されたくないコード. アプリであれば /internal/app ディレクトリに配置する(e.g.,/internal/app/myapp). また, それらプライベートなアプリから利用されるコードであれば /internal/pkg ディレクトリに配置する(e.g., /internal/pkg/myprivlib).
/pkg	外部のアプリから利用OKなライブラリコード.(e.g., /pkg/mypubliclib). 他のプロジェクトからこれらのライブラリが import されることを想定して, 本当にここにコードを配置すべきかはよく検討すべき. /pkg は一般的な構成パターンだが, ごく一部のコミュニティでは利用を推奨していない.
/vendor	アプリの依存関係(手動もしくは dep など, 任意の依存関係管理ツールで管理される). もしライブラリ開発のプロジェクトであれば, アプリの依存関係をコミットしてはいけない.
/api	OpenAPI/Swagger仕様, JSONスキーマ, プロトコル定義などを配置.
/web	WEBアプリの資材を配置する. 静的コンテンツやサーバサイドテンプレート、Single Page Applicationsなど.
/configs	アプリ設定ファイルのテンプレートやデフォルト設定を配置する.
/init	System init(systemd, upstart, sysv)やプロセスマネージャ/スーパーバイザ(runit, supervisord)の設定を配置.
/scripts	ビルドやインストール, 分析などの用途のスクリプトを配置. このディレクトリで root 階層の Makefile を小さく保つ.
/build	パッケージングやCIのために使用. AMIやDocker, OS(deb,rpm,pkg)のパッケージ設定やスクリプトを /build/package に配置する. CI(travis, circle, drone)設定は /build/ci に配置する.
/deployments	IaaS, PaaS, コンテナオーケストレーションなどのデプロイ設定やテンプレート(docker-compose, kubernetes/helm, mesos, terraform, bosh).
/test	追加のサードパーティテストアプリやテストデータ. 中の構成は自由で, /test/data や /test/testdata にデータを置いたり, /test/e2e というディレクトリを切ってテスト用のコードを配置したり.
/docs	デザインやユーザドキュメント(godocで生成したドキュメント以外に).
/tools	このプロジェクトのサポートツール. これらのツールは /pkg や /internal からコードを import 可能.
/examples	アプリやライブラリの使用例.
/third_party	外部のヘルパーツール, Forkしたコードやサードパーティユーティリティ(e.g., Swagger UI).
/githooks	Git hooks.
/assets	その他, リポジトリに関連する資材(images, logos, etc).
/website	Github pagesを利用していない場合はここにプロジェクトのWebサイト用データを配置.
/src	/src は使うべきではない.