Пожалуйста, хватит о чистой архитектуре микросервисов
Небольшой дисклеймер.
Я действующий 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.
Подписывайтесь на мой тгк
Также я оказываю услуги ментора
