Feature Based Clean Architecture. Часть 5: Масштабирование FBCA и теоретико-графовый анализ зависимостей

Если описать NestJS-архитектуру как граф — вершины это модули и классы, рёбра — зависимости между ними, — утверждение «архитектура не деградирует» перестаёт быть оценочным. Формально доказывается, при каких условиях циклы между модулями топологически невозможны, при каких размер публичного API не растёт с каждой новой ручкой, и при каких стоимость добавления фичи остаётся константой, а не растёт с числом существующих потребителей. Три измеримых структурных свойства, а не ощущение. Для типовой feature-based-структуры, которую сегодня продвигают как стандарт, ни одно из них не выполняется. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 5 — финал серии. Архитектурный подход, при котором эти три свойства соблюдаются (Feature-Based Clean Architecture), нагружается тем же сценарием годового роста, под весом которого деградирует обычный feature-based: партнёрка, анти-фрод, рефералки, расширенная аналитика, утроение модуля пользователей. Без художественности: реальный код, граф зависимостей «до» и «после», и формальное доказательство трёх свойств — DAG-инвариант, граница связности, O(1)-стоимость инкремента — на языке теории графов. Точка, в которой «архитектура не деградирует» становится не похвалой, а конкретным структурным утверждением.

https://habr.com/ru/articles/1038450/

#NestJS #TypeScript #Clean_Architecture #Архитектура_ПО #Бэкенд #Featurebased #Теория_графов #Масштабирование #DAG #DomainDriven_Design

Feature Based Clean Architecture. Часть 4: FBCA: формализация границ ответственности в NestJS-модуле

После трёх частей разбора деградации остаётся один вопрос: как написать NestJS-проект так, чтобы god-сервис и циклические зависимости были невозможны. «Писать аккуратнее», «лучше ревьюить», «выделять день в спринте на рефакторинг» — варианты, которые не работают: дисциплина не масштабируется на пятьдесят спринтов и пять команд. Работает другое — наложить на модуль структурные ограничения, которые TypeScript и NestJS DI просто не дадут нарушить. Слои, однонаправленные зависимости, изоляция домена от инфраструктуры — не папки ради порядка, а барьер, который физически не пропускает сценарии деградации из частей 1–3. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 4 — конкретная имплементация подхода на том же сквозном Twitter-подобном бэкенде. Как модуль режется на четыре слоя (domain / use-case / infrastructure / presentation), как раздутый сервис заменяется набором use-case’ов, куда уезжает работа с базой и почему оркестратор перестаёт быть god-функцией. Без художественности: реальный код, что именно изменилось по сравнению с feature-based-структурой из частей 1–3, и точка, в которой видно — прежние сценарии деградации теперь не запускаются не потому, что «все стали аккуратнее», а потому что нечем.

https://habr.com/ru/articles/1038438/

#NestJS #TypeScript #Clean_Architecture #Архитектура_ПО #Бэкенд #Featurebased #DomainDriven_Design #Слоистая_архитектура #Рефакторинг #SOLID

Feature Based Clean Architecture. Часть 3: Архитектурный риск циклов в NestJS: ROI решений на горизонте пяти лет

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

https://habr.com/ru/articles/1038426/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #Циклические_зависимости #featurebased #Технический_долг #ROI #Рефакторинг

Feature Based Clean Architecture. Часть 2: Декомпозиция на сервисы: анализ ограниченности подхода

Стандартный ответ на god-сервис — декомпозиция: разнести логику по нескольким сервисам с чёткими зонами ответственности, оставить тонкий оркестратор. После рефакторинга код действительно становится приятнее на глаз, файлов больше, метод оркестратора плоский. Структурно — не меняется ничего: тот же god-сервис воспроизводится этажом ниже, в одном из новых сервисов. На следующей итерации декомпозиции — ещё раз. Это не ошибка реализации, а свойство подхода. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

https://habr.com/ru/articles/1038416/

#nestjs #typescript #архитектура #бэкенд #антипаттерны #god_object #featurebased #технический_долг #рефакторинг #typeorm

Feature Based Clean Architecture. Часть 1: Эволюция NestJS-приложения в неподдерживаемое состояние

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

https://habr.com/ru/articles/1038240/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #God_object #Featurebased #Технический_долг #Рефакторинг #TypeORM

4 MVP за 4 месяца, 30 холодных DM, 1 регистрация: building in public по-русски

Меня зовут Никита, я бэкендер из Краснодара. Плотно сижу на NestJS/TypeScript в продуктовой команде. Параллельно с основной работой веду формат Proof of Work — 30-дневные публичные спринты по своим инди-проектам: каждый день рассказываю, что сделал, и не бросаю свои идеи в заметки Obsidian/Notion на годы (по крайней мере, теперь). За последние четыре месяца провёл четыре таких сезона: четыре продукта, четыре разных стека, четыре разных способа облажаться. Один продукт вообще не дожил до релиза. Три выпустил, ими пользуются люди, у одного есть публичный дашборд с метриками. Ни один пока не зарабатывает — и это часть истории, к которой я ещё вернусь. По итогам четырёх сезонов я мог бы написать «10 советов как сделать стартап», но таких текстов и без меня хватает. Здесь — конкретный разбор того, что у меня сработало, что не сработало и какой ценой. С цифрами, с названиями инструментов, с граблями, на которые я наступил лично. Если вы делаете свой инди-продукт или думаете начать — возможно, часть моего опыта сэкономит вам пару недель и замотивирует наконец начать. TL;DR. Без одного конкретного человека, который скажет «да, я этим воспользуюсь», лучше не начинать. Учить новый стек и параллельно гнать сроки — не получается, что-то одно. Email-верификация как блокер на регистрации убивает воронку. В РФ холодный аутрич без явного обмена «делаю → получаю» работает плохо. И выпуск продукта — начало работы, а не конец. Ниже подробно по каждому пункту, плюс отдельный раздел про юридическую часть и Telegram-релей в обход блокировок российского хостинга (которые как раз недавно начались в 2026).

https://habr.com/ru/articles/1035756/

#индиразработка #building_in_public #MVP #стартап #NestJS #Telegram_Bot_API #Cursor #Claude_Code #Proof_of_Work #солоразработчик

Откуда пришли пользователи: first-touch attribution для NestJS + React + Telegram Mini App в 100 строк кода

Я делаю голосовой AI-репетитор английского. Продукт живёт в трёх местах: веб-сайт speakwithai.pro , Telegram Mini App и Android-приложение в RuStore. У меня одна и та же база пользователей на NestJS + Postgres, и мне очень нужен ответ на вопрос: откуда вообще приходят люди? Yandex.Metrika и Google Analytics показывают только сайт. Telegram Mini App для них — чёрный ящик. Android-приложение через WebView — тоже. Из 6000 просмотров статьи на Habr я не мог сказать, сколько оттуда пришло в продукт, и через какой канал (TG, веб, app). Я не хотел тащить большую CDP вроде Mixpanel или Amplitude — для соло-разработчика это overkill. Вечером сел и сделал simplest-thing-that-could-possibly-work: одна колонка в БД, парсится при первом визите, читается на регистрации. 100 строк кода. Делюсь. Если интересно посмотреть на сам продукт — он живёт здесь: 🤖 Telegram-бот 🌐

https://habr.com/ru/articles/1030560/

#attribution #firsttouch_attribution #UTMметки #Telegram_Mini_App #start_param #NestJS #React #вебаналитика #TypeScript #маркетинговая_аналитика

Приложение полностью написанное AI

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

https://habr.com/ru/articles/1021492/

#ai #tailwind #angular #nestjs #postgresql #mobile_development