Я начал программировать с использованием Golang по-настоящему в этом году (2022), и сразу же начал искать рекомендации о том, как лучше всего развивать структуру проекта. Этот пост будет лишь одним из многих других, посвященных той же теме, и, возможно, именно поэтому я решил его написать.

Во-первых, golang уже совершенно отличается в том, как он работает с папками/пакетами, и, в целях улучшения, он имеет очень самоуверенную суть: во многих официальных документах сообщается, каким будет «goway» способ сделать что-то (полный не трогай меня), однако в том, как вы организуете свои файлы и папки, на самом деле нет определенного направления, поэтому каждый как бы дает свою собственную интерпретацию мира в этой части.

Я разделю этот пост на 3 отсылки, а затем покажу, как сочетание этих отсылок получилось в проекте.

Первая ссылка

Сложная система, которая работает, неизменно развилась из простой системы, которая работала.
-- Закон Галла

Для небольших приложений структура проекта должна быть простой.

Вторая ссылка

«Сообщество» провело исследование ряда исторических и новых шаблонов макетирования, распространенных в экосистеме Go. В этом опросе есть много интересных вещей, но мое внимание привлекли папки /cmd и /internal.

/cmd

Основные приложения для этого проекта.
Имя каталога для каждого приложения должно совпадать с именем желаемого исполняемого файла (например, /cmd/myapp).

/внутренний

Частное приложение и код библиотеки. Это код, который вы не хотите, чтобы другие импортировали в свои приложения или библиотеки. Обратите внимание, что этот шаблон макета налагается самим компилятором Go.

Третья ссылка

Архитектуры, которые лучше отделяют «детали» от того, что действительно приносит пользу.

Результат

Для простого приложения я стараюсь сделать его простым, однако, когда объем становится немного больше, я стараюсь провести небольшое различие между тем, что является «ядром»/предметом, и тем, что является деталями/инфраструктурой.

Обратите внимание, что в cmd у меня нет папки tuttipet, как предполагает эталонный проект. Сначала я попробовал использовать предложенный шаблон, но поскольку этот API уже вышел с интерфейсом командной строки и провайдером для terraform, я решил оставить его таким.

Быстро увеличьте ядро. Я стараюсь быть упрощенным и не создавать папки. Я поддерживаю только одну точку контакта с внешним миром (main.go), все, что обобщено, имеет свой собственный файл, а все, что не является таковым, остается в своем контексте, просто.

С помощью tuttipet.New (коротко, лаконично и запоминающе) «грязный» слой может взаимодействовать с вариантами использования (я считаю, что слово «использование» легче усвоить, чем «интерактор»)

Быстро увеличьте детали. Вот лишь инструменты, с помощью которых домен достигнет успеха.

Заключение

Я все еще слаб в пути, который предлагает Golang, и все еще пытаюсь понять, что с ним можно сделать, однако, хотя мне и не нравится способ выполнения некоторых вещей в Go, он оказался вполне простой и надежный.

Резюме: по возможности стараюсь сделать его простым, а если станет слишком сложным... Я вернусь к чертежной доске.

Другие ссылки

https://dev.to/booscaaa/implementando-clean-architecture-com-golang-4n0a
https://github.com/golang-standards/project-layout
https://blog.boot.dev/golang/golang-project-structure/
https://github.com/bnkamalesh/goapp
https://www.wolfe.id.au/2020/03/10/how-do-i-structure-my-go-project/
https://blog.logrocket.com/flat-structure-vs-layered-architecture-structuring-your-go-app/
https://developer20.com/how-to-structure-go-code/
https://dev.to/jinxankit/go-project-structure-and-guidelines-4ccm
https://github.com/bxcodec/go-clean-arch
https://golangexample.com/example-go-clean-architecture-folder-pattern/
https://www.calhoun.io/flat-application-structure/
https://go.dev/doc/efficient_go#names
https://go.dev/blog/имя-пакетов

Исходное сообщение: https://medium.com/@espigah/go-layout-do-projeto-18aacce8089d