Alai

Starting a Go Project の記事を読んだと仮定すると、最低限の Go Web サービスのスタート地点に立つことができたと言えるでしょう。 最初のプロジェクトでは、すべてのコードをプロジェクトのベースとなる 1 つのフォルダーに保存する方が簡単ですが、いつかは再構築したくなるものです。

この投稿では、Web サービスを構築する際に私が Go プロジェクトで従う構造の概要を説明します。

注意: サービスで使用したり、他の人と共有するライブラリを構築するだけなら、プロジェクトのベース フォルダにすべてを置いてもかまいません。

/cmd

このフォルダーには、プロジェクトのメイン アプリケーションのエントリ ポイント ファイルが含まれ、ディレクトリ名はバイナリの名前と一致しています。 例えば、cmd/simple-serviceは、私たちが公開するバイナリがsimple-serviceであることを意味します。

/internal

このパッケージは、サービスで使用するプライベートなライブラリコードを保持し、サービスの機能に固有のもので、他のサービスでは共有されません。 詳細は Go 1.4 リリース ノートを参照してください。

/pkg

このフォルダーには、他のサービスに利用されても問題ないコードが含まれます。 個人的には、internal よりもこのフォルダを使用することを好みます。

プロジェクトの構造

プロジェクトを構築する際、パッケージをどのように構成するかについて考慮すべき、いくつかの非常に重要な目標があります。

• Keep things consistent
• Keep things as simple as possible, but no simpler
• Loosely couple sections of the service or application
• Aim to ensure it a easy to navigate your way around

Over overall when getting started you have a bit experiment, try a few different ideas when building out your first and get some feedback on based on the above goals…プロジェクトを開始したら、上記の目標に基づいて、いくつかの異なるアイデアを試す必要があります。

一番の目標は、メンテナンスが簡単で、一貫性があり、信頼できるソフトウェアを構築することです。

例

私がどのようにプロジェクトを構成するかを見るために exitus を見ることをお勧めします。 トップレベルでは、各パッケージが何に関連しているかはかなり明確で、テストに偏りがあるものの、いくつかの例もあります。

$ tree exitus/ exitus/├─ cmd│ ├─ authtest│ │ └─ main.go│ ├─ backend│ │ └─ main.go│ └│ main── dev│ ├ add_migration.sh│ └── docker-compose.yml── Dockerfile├ go.mod├ go.sum│ ├ 20190721131113_extensions.down.sql│ ├── 20190721131113_extensions.up.Go│ └── client.go ├ └ ├ ├ └ └ └ └ └ └ └ └ └ ├ main── dev│ └ └ └ └ └ ├ └ └ └ └ ├ main ├migration.shsql│ ├ 20190723044115_customer_projects.down.sql│ ├ 20190723044115_customer_projects.up.sql│ ├ 20190726175158_issues.sql│ ├ 20190723044115_customer_projects.up.sqldown.sql│ ├─20190726175158_issues.up.sql│ ├─20190726201649_comments.down.sql│ ├─20190726201649_comments.up.sql│ ├─20190726201649_comments.up.sql│ ├ bindata.go│ ├──migrations_test.go│ └ README.md├──pkg│ ├──api│ ├ exitus.go│ ├ exitus.yml│ └ gen.go│ ├──auth│ ├ scope.go│ └ user.go│ ├── conf│ │ └── conf_test.go│ ├── db│ │ ├── db.go│ │ ├── migrate.go│ ├─ sqlhooks.go│ │ └─ transaction.go│ ├── env│ └── env.Go│ │ ├── env.Go│ │ ├── env.Go│ │ ├── env.Go│ ├── env.go│ │ ├── env.go│ │ ├── dev.go│ │ ├─ env.go│ ├─ env.go│ └── env.go│ │ ├── env.Gogo│ ├── healthz│ ├── healthz_test.go│ └── jwt│ └── jwt.go│ ├── metrics│ └── metrics.go│ ├── middleware│ └── middleware.go │ │ ├── healthz.go │ │ │ ├── healthz.go │ │ │ │ ├── healthz.go │ │ │ ├── healthz.gogo│ ├─ oidc│ └─ client.go│ ├─ server│ ├─ reflect.go│ └─ server.go│ └─ store│ ├─ comments_test.go│ ├─ customers.go│ ├─ customers_test.go│ ├─ issues.go│ └─ logo.go │ ├─ logo.go│ └─ logo.go│ └─ logo.go│ └─ logo.go│ ├─ logo.go│ ├─ logo.go│ └─ logo.go│ └─ logo.gogo│ ├ issues_test.go│ ├ migrate_test.go│ ├ projects.go│ ├ projects_test.go│ └ store.go └──────── README.md

ここでの目的は、プロジェクトをいくつかのファイルから、より大きな Web サービスに成長させる方法を説明することです。 githubのプロジェクトを漁って、他の開発者がどのように構成しているかを調べ、そして何よりも自分で試してみることをお勧めします！

• GopherCon EU 2018: Peter Bourgon – Best Practices for Industrial Programming
• Standard Go Project Layout
• GopherCon 2018を開催しました。 Cat Seeing – How Do You Structure Your Go Apps

Feedback

Feel free to reach out via:

• @ me on Twitter
• Send me an Email

• Starting a Go Project
• Building a WLToys A979 donkey car
• Cognitoで始めるには？
• Why CDK?
• Serverless Background jobs part 2