# Давайте подытожим раз и навсегда:

. Монолит – общая кодовая база, много команд, общие ресурсы, одно приложение, внутренняя коммуникация

. Модульный монолит – общая кодовая база, много / одна команда, общие / раздельные ресурсы, много приложений, внутренняя и внешняя коммуникация

. Микросервисы – раздельная кодовая база, одна команда, раздельные ресурсы, много приложений, внешняя коммуникация

# Словарь

. Приложение – запущенный на сервере процесс (инстанс), использующий какую-то кодовую базу для решения набора бизнес-задач. Инстансов у одного приложения может быть много.

. Команда – набор специалистов, имеющих постоянную коммуникацию и разрабатывающих одни и теже приложения.

. Кодовая база – сокращенно от "кодовая база приложения", то есть, код, описывающий специфичный (уникальный) для вашего приложения процесс (синонимы – "бизнес-логика", "фича")

. Ресурсы – инфра (БД, кэши, fs, транспорт, etc.) переиспользуется между приложениями

. Внутренняя коммуникация – вызов бизнес-логики внутри одного приложения засчет вызова функции изнутри кода

. Внешняя коммуникация – вызов бизнес-логики из другого приложения с использованием какого-либо транспорта (TCP, HTTP, MQ, 2IP, stdin, etc.)

# Подставим значения из словаря

. Монолит – много команд пилят фичи в рамках 1-ой кодовой базы; для исполнения какой-то фичи можно вызвать функцию изнутри самого приложения, которую могла написать другая команда; при этом вся кодовая база шерит туже БД, кэш, fs; запускается это все в одно приложение (но может быть в множество инстансов, если, например, кроны выделили)

. Модульный монолит – много или одна команда пилит фичи в рамках 1-ой кодовой базы; для исполнения какой-то фичи можно вызвать функцию изнутри самого приложения или сделать запрос к другому приложению (например, в рамках модульного монолита), при этом можно шерить туже БД, кэш, fs, а можно не шерить; запускается это все в рамках множества приложений

. Микросервис – пилит одна команда; для исполнения какой-то фичи нужно сделать запрос к другому микросервису; свои собственные БД, кэш, fs; запускается это все в рамках множества приложений

# Выводы

. Несомненно, бывают и другие вариации, но в 90% случаев части системы можно классифицировать именно так

. Ваша система может состоять одновременно из Микросервисов, Монолитов и Модульных Монолитов

. Модульный монолит – самый гибкий вариант, потому что позволяет реализовать множество приложений, которым не придется использовать межсервисную коммуникацию (потому что можно просто вызвать функцию изнутри кода), а при надобности можно воспользоваться и межсервисными запросами

(продолжение ниже)

# Эволюция системы здорового человека:

. Каждая команда создает свои модульные монолиты

. Отдельные приложения создается не «на глаз» а только если (1) оно должно существовать на отдельной машине (например, в определенной геолокации), (2) оно stateful (держит сокеты), (3) оно реализует отдельный набор фич (API для партнеров), (4) должно иметь выделенные ресурсы железа (CPU, GPU, RAM, network), (5) использует мешает исполнению другой кодовой базы (CPU-intensive)

. Если в рамках одной команды какой-то код должен быть вынесен отдельно (чаше всего, из-за вопроса безопасности), тогда он превращается в микросервис.

. Если есть stateful приложения или микросервисы, тогда используем межсервисную коммуникацию, в остальных случаях, вызываем фичи изнутри приложения

. Все.

# Эволюция множества команд разработки

. "Монолиты – это старье, го в микросервисы" ИЛИ "Мы не умеем организовывать кодовую базу, чтобы несколько команд могли над ней работать, го в микросервисы"

. Делят вся системы на кучу микросервисов чисто "ну я так вижу"

. Ебутся с межсервисный коммуникаций, транзакциями, тестами и дебагингом

. Приходят новые требования, которые не укладываются в текущее разделение

. Ловят межсервисный дедлуп

. Ебутся с коммуникаций, транзакциями, тестами и дебагингом в 10 раз больше

. (если повезет) Начинают объеденять микросервисы в модульные монолиты

. (но скорее всего) Увольняются и оставаляют это легаси будущим разрабам, которые такие: "О, да тут микросервисы! Значит так и надо. Заебись."

. Цикл микросервисов и ебли, делает новый оборот

P.S.

Покажу пример каждого в будущем посте с описание go boilerplate

А еще всем прочитавшим: мне так не нравится название "распределенный монолит", потому что, ну... он же не "distributed'... это скорее про то, что мы одну и туже кодовую базу можем запускать в множестве разных приложений и не использовать межсервисную коммуникацию, то есть он скорее "partitioned", но тоже не звучит

Короче, нужны ваши идеи или может вы слышали другое название

Еще есть модульные монолиты. Мне нравится как Polylith устроен https://polylith.gitbook.io/polylith/introduction/polylith-in-a-nutshell

Хм, ну "модульный" звучит лучше, да

(самое смешное, что у меня есть вторая книга, которую я скоро анонсирую и я сейчас посмотрел я там это тоже "модульные монолиты" называю))

Какая 2 книга?

Про best practice в веб и в целом в программировании

Я уже начинал ее писать и постил, из нее вытек ФОП, а теперь я переписал с нуля и хочу сделать полновесную презентацию

Если что, про ФОП я не забыл, его тоже будем продвигать и обязательно сделаю публичным твой вклад) Я просто слишком быстро написал ту и пока придерживаю ее в рукаве

еще хорошо бы чтобы мой код кто-то посмотрел, а то может я там дичь написал полную🌚🌚🌚

Не переживай, я там тоже дичи написал, куча людей посмотрела, пока никто не заметил))

Я кста заметил там в конце про собаку или что-то такое и она там дичь делает🌚🌚🌚