20 разрабов коммитят в один монолит: непонятно, кто за что отвечает, конфликты в коде, долгий онбординг, низкая продуктивность. Знакомо?

А теперь представьте масштаб проблемы, если их не 20, а сотни, в одном репозитории 2,2 миллиона строк кода, а проекту больше десяти лет.

Это GitLab, и их решение - срочно нарезать всё на микросервисы. На самом деле нет, да это и невозможно на таком масштабе, поэтому делают модульный монолит и меняют правила работы команд.

Этой инициативе уже несколько лет, но долгое время работа шла довольно вяло. С развитием агентной разработки пришлось ускориться ✊

Давайте посмотрим, что происходит - далеко не каждая компания открывает свои ADR.

Все эти годы проект рос, местами было больно - впрочем, ничего необычного.

Почему? - не было нормальных границ между частями системы в монолите и чёткой структуры - даже якобы изолированный код использует одни и те же таблицы в бд (привет, intrusive/data coupling) - т.о. в отдельные сервисы не выделишь, слишком большая связанность - инфраструктурный каплинг, естественно - части монолита связаны намертво и деплоить нужно вместе - а значит нельзя закатить хотфикс без полного обновления - косяк одного домена может положить все остальные

Размытые границы доменов - это тяжело и для людей, и для агентов. Но если разработчики с опытом на проекте могут положиться на накопленные знания: им понятно, что лучше не трогать, где спросить коллегу, то агент этого не "чувствует". В итоге - случайно ломает логику в другом домене или дублирует то, что уже есть (хотя с кем из людей такого не бывало 😏)

Ускорение с приходом агентной разработки выглядит как "ну для разрабов было неудобно, но кого это волновало".... А вот для агентов пришлось постараться ))  Конечно, у бизнеса появилась необходимость эффективно использовать ai.

Как делают: 1) вынесли либы ( lib/gitlab ) в гемы в определённом порядке - от слабо-связанных с доменной логикой к сильно-связанным [ADR-004]      - первый этап - универсальные утилиты, не связанные с доменной логикой (критерий - связи с active_record)      - второй - библиотеки, которые ссылаются на концепции gitlab, но не на модели      - третий - зависящий от ar-моделей код - не выносится в гемы, а перемещается в свой bounded context 2) определили bounded contexts и ответственные команды (на самом деле "стюардов", но об этом отдельно) 3) изолируют доменный слой 4) выделяют транспортный слой по правилам гексагональной архитектуры: это адаптеры web ui, rest api, graphql, sidekiq

Для определения и форсирования границ используют danger-packwerk на ci в мягком варианте - комментарии для новых нарушений + package_todo.yml в репах для фиксации старых.

На фронтенде: строят микрофронтенды внутри монолита, так чтобы каждый модуль можно было деплоить самостоятельно.

Так в гитлабе делают каплинг более явным и управляемым, к этому, пожалуй, нужно стремиться нам всем ✊

А вам приходилось работать над разделением монолита на модули? Какие инструменты использовали для форсирования границ?