Небольшой дисклеймер

Я действующий senior golang разработчик. В связи с чем, могу заявить, что данное мнение является полностью неоспоримым. Вашего объективного мнения не существует, существует только субъективное, ибо мы с вами не камни. Камень - объект, человек - субъект. Может ли субъект родить что-то объективное? Но да ладно, меня понесло.

Точка отправления номер раз

Когда я был новичком, я выстроил страшный конвейер "чистых" микросервисов. В тот момент, я понял, что так дальше так дела не пойдут. Я начал изучать что это за монстр такой "чистая архитектура". Прочитал несколько известных книг. Но мне подвернулась моя первая работа. И вот я пришел, и услышал, что у них самые чистые сервисе в мире. Я с круглыми глазами смотрел на такие папки как "internal", "pkg", "storage", "api", где всегда есть файлы "entity" с интерфейсами, "const" с константами и дальше опционально, базы данных, протоколы...

Тогда, я как настоящий джун принял это все на веру. И вот я меняю место работы. А там сервисы делают иначе. У нас есть самый лучший в мире шаблон, делай по нему. Папка gRPC теперь в корне, а не в папке api/gRPC, чтобы импортировалось. База данных теперь это "repo", константы теперь лежат в entity, а интерфейсы там, где используются.

Я уже тогда начал о чем-то подозревать, пока не был поражен "СУПЕРМЕГАЧИСТОМУ" сервису в следующей компании. Большие. Сложные. Запутанные. Монолиты.... Которые кстати микросервисы. Мне пришлось месяц разбираться что как работает и где лежит. Огромные вложенности, какие-то dto, дублирующие модели для каждого действия... Жду комменты, что джуном так и остался, раз не смог разобраться.

Единственное, что всегда неизменно, cmd/main. Спасибо и на этом.

Точка отправления номер два

Что я вообще хочу сказать? Я понимаю, что ваш сервис самый лучший, что его разрабатывала целая корпорация индусов вам под заказ, но так получается, что такое происходит в каждой компании. Я не говорю о том, что давайте примем один стандарт, это невозможно. И не говорю о том, чтобы выявить какие-то подходы, они либо есть, либо появятся сами собой. Я хочу сказать, что может мы не будем пинать новичков и доказывать коллегам с морем у рта, что он со своим подходом может идти в крипто-стартап? 

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

Точка отправления номер три

От количества материала, который написан на эту тематику, разных картинок и прочее у меня у самого возникает чувство отторжения. Везде пишут с разными отличиями, что сделаю и я. Тут сугубо для новичков, которые хотят "клепать" что-то похожее на правду. А там, как устроитесь, то смотрите на другие сервисы и придерживайтесь правилам, которые зародились в компании. 

Пример микросервиса

Ниже я приведу пример и распишу про каждый компонент.

В корне мы имеем три папки:

• cmd и в ней сразу main.go - то единственное, что есть в каждой компании. Это наша точка входа в приложение. Тут все инициализируется и запускается

• internal - папка с внутренними модулями. Сюда мы запихиваем разные api, db, и так называемую "бизнес логику"

• pkg - пакеты, которые можно просто перенести в другой сервис. Например клиент для общения со сторонним сервисом. Или пакет для отправки сообщений в Кафку. 

Также есть другие файлы:

• env - тут переменные для запуска

• gitignore - сюда закидываем то, что не должно улетать в репозиторий

• gitlab-ci - сугубо потому, что многие компании сейчас используют гитлаб

• taskfile - очень удобная вещь, идите гуглить

Теперь пойдем по порядку - pkg. Сюда мы добавляем то, что я могу скопировать и вставить в другой проект. Разные клиенты для отправки запросов в основном. 

Папка internal. Тут, зачастую, четыре папки:

• api - тут у нас наши методы, которые будут у сервиса. Обычный роутер и хендлер с обработчиками. Тут все, что связано с сервером.

• config - структура с вложенными структурами. Это наши конфигураторы. Создаем главную структуру "Config", а в ней вложенные структуры для баз данных, сервера, просто переменные, которые нам необходимы. Он загружается в мейне и передается в соответствующие структуры.

• repo - тут создаем тесную связь с нашей базой данных. разные методы, которые обеспечивают CRUD

• service - структура с методами для бизнес логики.

Общие принципы - в entity записываем и константы и интерфейсы. Также, в папках, где это нужно - генерируем моки. Структуры везде неэкспортируемые ( с маленьких букв). Встраиваем интерфейсы и общаемся через них.

В сухом остатке

Если вы новичок, то всего вышесказанного вам должно быть достаточно. А если вы специалист с опытом, то я рад за то, что ты потратил время на данную статью. Будьте добрее к новичкам, а новички будьте более гибкими, у каждой компании есть свои правила и обычаи, ваше видение чистого кода и правильно построенного микросервиса нужны только в стартапе, где вы будете первым разработчиком.

Так говорит kam1dere. 

Подписывайтесь на мой тгк

Также я оказываю услуги ментора