У нас в команде был показательный кейс: полгода вылизывали код, дробили сервисы по SOLID, выносили всё в общие библиотеки — в итоге получили «идеальный» монолит в распределённой обёртке. Каждый микросервис блестел чистотой, но при попытке масштабировать систему упёрлись в адские cross-service зависимости. Например, сервис нотификаций вызывал 5 других сервисов через цепочку RPC, чтобы собрать данные для письма — латенси ползла в ..
Пришлось экстренно пересматривать архитектуру: слепить несколько сервисов обратно в рамках bounded context, разрешить контролируемое дублирование DTO и убить «общие» библиотеки. Код внутри сервисов стал менее «чистым» (например, появились god-классы для локальной агрегации данных), но общая система задышала.
Сейчас ловлю себя на мысли, что архитектурные решения вроде верного разделения контекстов дают на порядок больше, чем рефакторинг ради следования принципам. Коллеги, как вы определяете точку, где пора остановить рефакторинг и переключиться на перепроектирование границ? Есть ли у вас метрики (типа коэффициента связности сервисов) или больше через боль и крики бизнеса?
Короче, в последнее время все эти новые фреймворки и языки — это как тренды на ютуб: появляются, исчезают, а ты пытаешься понять, зачем они вообще были нужны. Всё больше народ лезет в “экосистемы” и пытается угнаться за какими-то новыми фичами, но по факту всё сводится к одному — чтобы оставаться в игре, нужно быть в тренде. Вроде и хорошая идея, но чем больше таких инструментов, тем сложнее выбрать нормальный и не сдохнувший через пару лет.
Не, я не против, когда есть какие-то крутые новшества, но как-то у меня ощущение, что каждая новая фича или “язык” создается скорее для того, чтобы держать разработчиков в плену. Вроде бы ты хочешь улучшить код, а на деле тебе просто предлагают еще один набор зависимостей и библиотек, которые нужно изучить, чтобы не остаться за бортом.
У нас в команде был показательный кейс: полгода вылизывали код, дробили сервисы по SOLID, выносили всё в общие библиотеки — в итоге получили «идеальный» монолит в распределённой обёртке. Каждый микросервис блестел чистотой, но при попытке масштабировать систему упёрлись в адские cross-service зависимости. Например, сервис нотификаций вызывал 5 других сервисов через цепочку RPC, чтобы собрать данные для письма — латенси ползла в ..
Пришлось экстренно пересматривать архитектуру: слепить несколько сервисов обратно в рамках bounded context, разрешить контролируемое дублирование DTO и убить «общие» библиотеки. Код внутри сервисов стал менее «чистым» (например, появились god-классы для локальной агрегации данных), но общая система задышала.
Сейчас ловлю себя на мысли, что архитектурные решения вроде верного разделения контекстов дают на порядок больше, чем рефакторинг ради следования принципам. Коллеги, как вы определяете точку, где пора остановить рефакторинг и переключиться на перепроектирование границ? Есть ли у вас метрики (типа коэффициента связности сервисов) или больше через боль и крики бизнеса?
После выхода qwen 3, сомневаюсь что из бесплатных версий есть что то лучше, но о3 тоже неплохая модель
Короче, в последнее время все эти новые фреймворки и языки — это как тренды на ютуб: появляются, исчезают, а ты пытаешься понять, зачем они вообще были нужны. Всё больше народ лезет в “экосистемы” и пытается угнаться за какими-то новыми фичами, но по факту всё сводится к одному — чтобы оставаться в игре, нужно быть в тренде. Вроде и хорошая идея, но чем больше таких инструментов, тем сложнее выбрать нормальный и не сдохнувший через пару лет.
Не, я не против, когда есть какие-то крутые новшества, но как-то у меня ощущение, что каждая новая фича или “язык” создается скорее для того, чтобы держать разработчиков в плену. Вроде бы ты хочешь улучшить код, а на деле тебе просто предлагают еще один набор зависимостей и библиотек, которые нужно изучить, чтобы не остаться за бортом.