2020-05-25 補足
コメントをいただきましたので追記。
Russ Cox からGoの標準じゃないとクレームがついてますね。
https://github.com/golang-standards/project-layout/issues/117
はじめに
Go初学者です。
Goのパッケージ構成に悩みGithubを調べると、ちょこちょこ見かけるこれ
Standard Go Project Layout
スター数は1.5万超です。
もしこれがGoなりのスタンダードであるならば、自身のパッケージ構成の参考になりそうですので調べてみました。
もちろん実際には各プロジェクトや利用用途、採用するデザインパターンなどによってはもっと扱いやすい形があるかもしれませんl
実際私もDDDが好みなので、導入する際はDomainでディレクトリを切り分けたいなと思っています。
Standard Go Project Layout is 何
以下のGithubリポジトリを指します。
Standard Go Project Layout
Cloneして構造を確認
$ find . | sed -e 's/^.//'
/init
/cmd
/cmd/_your_app_
/tools
/test
/Makefile
/web
/web/app
/web/template
/web/static
/website
/internal
/internal/app
/internal/app/_your_app_
/internal/pkg
/internal/pkg/_your_private_lib_
/docs
/README.md
/third_party
/examples
/configs
/scripts
/api
/githooks
/build
/build/ci
/build/package
/assets
/vendor
/deployments
/pkg
/pkg/_your_public_lib_
前置き部分
This is a basic layout for Go application projects. It's not an official standard defined by the core Go dev team; however, it is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of these patterns are more popular than others. It also has a number of small enhancements along with several supporting directories common to any large enough real world application.
これは、Goアプリケーションプロジェクトの基本的なレイアウトです。これは、コアとなるGo開発チームによって定義された公式の標準ではありませんが、Goエコシステムの中で、歴史的に共通しているプロジェクトのレイアウトパターンのセットとなっています。これらのパターンの中には、他のパターンよりも人気のあるものもあります。また、現実世界の大規模なアプリケーションに共通するいくつかのサポートディレクトリに加えて、いくつかの小さな機能強化が行われています。
If you are trying to learn Go or if you are building a PoC or a toy project for yourself this project layout is an overkill. Start with something really simple (a single main.go file is more than enough). As your project grows keep in mind that it'll be important to make sure your code is well structured otherwise you'll end up with a messy code with lots of hidden dependencies and global state. When you have more people working on the project you'll need even more structure. That's when it's important to introduce a common way to manage packages/libraries. When you have an open source project or when you know other projects import the code from your project repository that's when it's important to have private (aka internal) packages and code. Clone the repository, keep what you need and delete everything else! Just because it's there it doesn't mean you have to use it all. None of these patterns are used in every single project. Even the vendor pattern is not universal.
Goを学ぼうとしている場合や、自分でPoCやおもちゃのプロジェクトを構築しようとしている場合、このプロジェクトレイアウトはやりすぎです。最初は本当にシンプルなものから始めてください（main.goファイルが1つあれば十分です）。プロジェクトが大きくなってくると、コードがきちんと構造化されているかどうかが重要になってくることを覚えておいてください。そうしないと、多くの隠れた依存関係やグローバルな状態を持つ厄介なコードになってしまいます。プロジェクトで作業する人が増えれば、さらに多くの構造が必要になります。そこで、パッケージやライブラリを管理するための共通の方法を導入することが重要になります。オープンソースプロジェクトがある場合や、他のプロジェクトがプロジェクトリポジトリからコードをインポートしていることを知っている場合は、プライベートな(内部的な)パッケージやコードを持つことが重要になります。リポジトリをクローンして、必要なものだけを残し、他のものはすべて削除してください。リポジトリにあるからといって、すべてを使わなければならないわけではありません。これらのパターンはすべてのプロジェクトで使われているわけではありません。ベンダーパターンでさえも、万能ではありません。
各ディレクトリの分類と説明
Go Drirevcories
/cmd
Main applications for this project.
The directory name for each application should match the name of the executable you want to have (e.g., /cmd/myapp).
Don't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the /pkg directory. If the code is not reusable or if you don't want others to reuse it, put that code in the /internal directory. You'll be surprised what others will do, so be explicit about your intentions!
It's common to have a small main function that imports and invokes the code from the /internal and /pkg directories and nothing else.
このプロジェクトの主なアプリケーション。
各アプリケーションのディレクトリ名は、欲しい実行ファイルの名前と一致するようにしてください(例: /cmd/myapp)。
アプリケーションディレクトリには多くのコードを入れないようにしましょう。コードをインポートして他のプロジェクトで使えると思うならば、/pkg ディレクトリに置くべきです。コードが再利用できない場合や、他の人に再利用してほしくない場合は、そのコードを /internal ディレクトリに置いてください。他の人が何をするか驚くでしょうから、自分の意図を明確にしてください。
このような場合は、/internal ディレクトリと /pkg ディレクトリからコードをインポートして呼び出す小さなメイン関数を持つのが一般的ですが、それ以外は何もしません。
Dockerの/cmd配下をみていると、ディレクトリが一つだけ格納されており、
中はpakcage mainのシンプルなソースコードとテストコード、OS別の設定ファイル等が入っていました。なるほど。
moby/cmd/dockerd/
- README.md
- config.go
- config_common_unix.go
- config_unix.go
- config_unix_test.go
- config_windows.go
- daemon.go
- daemon_freebsd.go
- daemon_linux.go
- daemon_unix.go
- daemon_unix_test.go
- docker.go
- docker_unix.go
- docker_windows.go
- metrics.go
- options.go
- options_test.go
- service_unsupported.go
- service_windows.go
/internal
Private application and library code. This is the code you don't want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 release notes for more details. Note that you are not limited to the top level internal directory. You can have more than one internal directory at any level of your project tree.
You can optionally add a bit of extra structure to your internal packages to separate your shared and non-shared internal code. It's not required (especially for smaller projects), but it's nice to have visual clues showing the intended package use. Your actual application code can go in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).
プライベートなアプリケーションやライブラリのコード。これは、他の人が自分のアプリケーションやライブラリにインポートしたくないコードです。このレイアウトパターンは、Goコンパイラによって強制されることに注意してください。詳細については、Go 1.4のリリースノートを参照してください。トップレベルの内部ディレクトリに限定されないことに注意してください。プロジェクトツリーのどのレベルでも、複数の内部ディレクトリを持つことができます。
オプションで、内部パッケージに少し余分な構造を追加して、共有内部コードと非共有内部コードを分離することができます。(特に小規模なプロジェクトでは) 必須ではありませんが、パッケージの使用目的を示す視覚的な手がかりがあるのは良いことです。実際のアプリケーションコードは /internal/app ディレクトリ (例: /internal/app/myapp) に、それらのアプリケーションで共有されるコードは /internal/pkg ディレクトリ (例: /internal/pkg/myprivlib) に置くことができます。
ライブラリとして公開する際に、利用者へ隠したいコードをここに配置するかなと。
前述の通り利用しないのであれば、不要なディレクトリになるかもしれません。
/pkg
Library code that's ok to use by external applications (e.g., /pkg/mypubliclib). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the internal directory is a better way to ensure your private packages are not importable because it's enforced by Go. The /pkg directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The I'll take pkg over internal blog post by Travis Jeffery provides a good overview of the pkg and internal directories and when it might make sense to use them.
It's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: Best Practices for Industrial Programming from GopherCon EU 2018, GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps and GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go).
See the /pkg directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it's not universally accepted and some in the Go community don't recommend it.
外部アプリケーションで使用しても問題ないライブラリコード(例: /pkg/mypubliclib)。他のプロジェクトは、これらのライブラリが動作することを期待してインポートしますので、ここに何かを置く前によく考えてください :-)。内部ディレクトリは、プライベートパッケージがインポートできないようにするためのより良い方法であることに注意してください。/pkg ディレクトリは、そのディレクトリにあるコードが他の人に使われても安全であることを明示的に伝える良い方法です。I'll take pkg over internal blog post by Travis Jeffery は、pkg ディレクトリと内部ディレクトリの概要と、それらを使用することが意味のある場合の概要を提供しています。
また、ルートディレクトリにGo以外のコンポーネントやディレクトリが多く含まれている場合に、Goコードを一箇所にまとめておく方法でもあります。GopherCon EU 2018、GopherCon 2018からの産業用プログラミングのベストプラクティス。Kat Zien - How Do You Structure Your Go Apps and GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go）。)
このプロジェクトレイアウトパターンを使用している人気のある Go repos を見たい場合は /pkg ディレクトリを参照してください。これは一般的なレイアウトパターンですが、普遍的に受け入れられているわけではありませんし、Goコミュニティの中には推奨していない人もいます。
ライブラリやOSSとして公開されているプロジェクトがよく/pkgディレクトリを持っていますね。
/vendor
Application dependencies (managed manually or by your favorite dependency management tool like the new built-in Go Modules feature). The go mod vendor command will create the /vendor directory for you. Note that you might need to add the -mod=vendor flag to your go build command if you are not using Go 1.14 where it's on by default.
Don't commit your application dependencies if you are building a library.
Note that since 1.13 Go also enabled the module proxy feature (using proxy.golang.org as their module proxy server by default). Read more about it here to see if it fits all of your requirements and constraints. If it does, then you won't need the vendor directory at all.
アプリケーションの依存関係 (手動で管理するか、新しい組み込みの Go Modules 機能のようなお気に入りの依存関係管理ツールで管理します)。go mod vendorコマンドは、/vendorディレクトリを作成します。デフォルトでオンになっている Go 1.14 を使用していない場合は、go ビルドコマンドに -mod=vendor フラグを追加する必要があるかもしれないことに注意してください。
ライブラリをビルドしている場合は、アプリケーションの依存関係をコミットしないでください。
1.13 以降、Go はモジュールプロキシ機能も有効にしています (デフォルトでは proxy.golang.org をモジュールプロキシサーバとして使用しています)。この機能についての詳細は、ここを読んで、あなたの要件や制約に適合するかどうかを確認してください。そうであれば、ベンダディレクトリは全く必要ありません。
Service Application Directories
/api
OpenAPI/Swagger specs, JSON schema files, protocol definition files.
OpenAPI/Swaggerの仕様、JSONスキーマファイル、プロトコル定義ファイル。
Web Application Directories
/web
Web application specific components: static web assets, server side templates and SPAs.
ウェブアプリケーション固有のコンポーネント：静的ウェブアセット、サーバーサイドテンプレート、SPA。
ウェブアプリケーションを作成する際に利用するディレクトリ。
フロントを別リポジトリに切り出したりせずに利用するパターンって、サンプル探しましたがあまりなかった。。
Common Application Directories
/config
Configuration file templates or default configs.
Put yourconfdorconsul-templatetemplate files here.
設定ファイルのテンプレートまたはデフォルトの設定。
confdまたはconsul-templateテンプレートファイルをここに置きます。
/init
System init (systemd, upstart, sysv) and process manager/supervisor (runit, supervisord) configs.
システムinit(systemd, upstart, sysv)とプロセスマネージャ/スーパーバイザ(runit, supervisord)の設定。
/scripts
Scripts to perform various build, install, analysis, etc operations.
These scripts keep the root level Makefile small and simple (e.g., hashicorp/terraform:Makefile@master).
様々なビルド、インストール、解析などの操作を行うためのスクリプトです。
これらのスクリプトはルートレベルの Makefile を小さくシンプルに保ちます (例: hashicorp/terraform:Makefile@master)。
例示されているterraformのscriptsを確認しました。
上記の通り、Makefileで呼ばれている物も多く、ビルド時の解析などを切り出して格納されている様です。
terraform/scripts
/build.sh
/changelog-links.sh
/debug-terraform
/dist.sh
/generate-plugins.go
/generate-plugins_test.go
/gofmtcheck.sh
/gogetcookie.sh
/protobuf-check.sh
/build
Packaging and Continuous Integration.
Put your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the /build/package directory.
Put your CI (travis, circle, drone) configurations and scripts in the /build/ci directory. Note that some of the CI tools (e.g., Travis CI) are very picky about the location of their config files. Try putting the config files in the /build/ci directory linking them to the location where the CI tools expect them (when possible).
パッケージングと継続的インテグレーション。
クラウド (AMI)、コンテナ (Docker)、OS (deb、rpm、pkg) パッケージの設定とスクリプトを /build/package ディレクトリに置きます。
CI (travis, circle, drone) の設定とスクリプトを /build/ci ディレクトリに配置します。CIツールの中には（Travis CIなど）、設定ファイルの場所に非常にこだわるものがあることに注意してください。コンフィグファイルを/build/ciディレクトリに置き、CIツールが期待する場所にリンクしてみてください（可能であれば）。
/deployments
IaaS, PaaS, system and container orchestration deployment configurations and templates (docker-compose, kubernetes/helm, mesos, terraform, bosh).
Note that in some repos (especially apps deployed with kubernetes) this directory is called /deploy.
IaaS、PaaS、システム、コンテナオーケストレーションのデプロイメント設定とテンプレート (docker-compose、kubernetes/helm、mesos、terraform、bosh)。
いくつかのリポジトリ (特に kubernetes でデプロイされたアプリ) では、このディレクトリは /deploy と呼ばれていることに注意してください。
docker-composeやterradormなどの環境やデプロイ時に利用するファイルをまとめている様です。
/test
Additional external test apps and test data. Feel free to structure the /test directory anyway you want. For bigger projects it makes sense to have a data subdirectory. For example, you can have /test/data or /test/testdata if you need Go to ignore what's in that directory. Note that Go will also ignore directories or files that begin with "." or "_", so you have more flexibility in terms of how you name your test data directory.
追加の外部テストアプリとテストデータ。testディレクトリは自由に構成してください。大規模なプロジェクトでは、データのサブディレクトリを持つことは理にかなっています。例えば、/test/data や /test/testdata などのディレクトリが必要な場合、そのディレクトリにあるものを無視することができます。Go は "." や "_" で始まるディレクトリやファイルも無視するので、テストデータディレクトリの名前の付け方に柔軟性があることに注意してください。
このディレクトリはプロジェクトによって柔軟にディレクトリを構成することが推奨されていますね。
例示されているOpenShiftのtestの中身を確認すると、
拡張テスト、e2e、統合テストなどに切り分けて格納されています。
openshift/test
/e2e
/extended
/integration
Other Directories
/docs
Design and user documents (in addition to your godoc generated documentation).
デザインドキュメントとユーザードキュメント (godocで生成されたドキュメントに加えて)。
例示されているOpenShiftのdocsの中身を確認すると、
利用方法などを記載したmdファイルや、フロー図のpdf等、プロジェクトに関係のあるドキュメントが格納されています。
/tools
Supporting tools for this project. Note that these tools can import code from the /pkg and /internal directories.
このプロジェクトをサポートするツールです。これらのツールは /pkg と /internal ディレクトリからコードをインポートできることに注意してください。
プロジェクト内でのみ利用するツール等を入れている様です。
コードの自動生成を行うためのShellなどが入っているようです。
/examples
Examples for your applications and/or public libraries.
あなたのアプリケーション、またはpublic librariesのための例。
ライブラリを利用するための実装例や、アプリケーションの実行例などを格納する場所の様です。
例示されているHugoのサンプルでは、Hugoでブログを実装する際に
フォークする内容を格納しています。
/gohugoio/hugo/examples
/blog
/content
/layouts
/static
/third_party
External helper tools, forked code and other 3rd party utilities (e.g., Swagger UI).
外部ヘルパーツール、フォークされたコード、その他のサードパーティ製ユーティリティ（Swagger UIなど）。
例示されているSwagger UIとは、Swagger Specで記述したYAMLやJSONファイルからAPIインタフェース仕様ドキュメントを自動生成できるツールです。
ドキュメント自動生成用のファイル（yaml, JSONファイル）などはこちらに格納する様です。
/githooks
Git Hooks.
Githookを作成する場合はこちらに格納する様です。
/assets
Other assets to go along with your repository (images, logos, etc).
リポジトリに付随するその他のアセット（画像、ロゴなど）。
静的なイメージデータ等はこちらで管理する様ですね。
/website
This is the place to put your project's website data if you are not using Github pages.
Githubページを使用していない場合は、プロジェクトのWebサイトのデータを置く場所です。
例示されているこちらのサンプルですと、静的ページを格納している様です
/hashicorp/vault/website
/components
/data
/layouts
/pages
/public
作成してはいけないディレクトリ
/src
Some Go projects do have a src folder, but it usually happens when the devs came from the Java world where it's a common pattern. If you can help yourself try not to adopt this Java pattern. You really don't want your Go code or Go projects to look like Java :-)
Goプロジェクトの中にはsrcフォルダを持っているものもありますが、これは通常、開発者が一般的なパターンであるJavaの世界から来た場合に起こります。可能であれば、このようなJavaのパターンを採用しないようにしてください。あなたのGoコードやGoプロジェクトがJavaのように見えることは本当に避けてください。
参考
www.DeepL.com / Translator（無料版）で翻訳しました。