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` は使うべきではない.