Проектирование и рефакторинг *

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает.

Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров. Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами.

Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении.

Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно.

На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается.

Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними.

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

Navisworks хорошо находит BIM‑коллизии, а Revit — инструмент для исправления. Но между ними часто остаётся хаос: XML и HTML‑отчёты, Excel, переписки, ручной поиск ID и вопросы руководителей в стиле «ну как там с коллизиями?».

Я расскажу, как из этой боли вырос внутренний web‑сервис Clash Analytics: импорт XML‑отчётов Navisworks, аналитика по проектам, история коллизий, статусы, комментарии, назначение отделам и локальный Revit Bridge, который открывает проблемное место в модели за один клик.

У нас было 2 телефонии от разных вендоров, одна речевая аналитика и 300 тысяч звонков в месяц. И задача: сделать сквозную аналитику по звонкам сотрудников.

Привет! Я Никита, инженер системного проектирования в компании Передовые Платежные Решения. Расскажу, как мы использовали единый идентификатор через службу каталогов Active Directory (AD), и стали точно определять, кому из сотрудников принадлежит звонок. Независимо от того, из какой телефонии он исходит.

Наш опыт может быть полезен архитекторам, инженерам и техническим лидерам команд, которым предстоит интеграция разнородных систем телефонии.

Дебаты, касающиеся программирования с применением агентов, в основном касаются подбора инструментария: какую IDE, какую модель, какой CLI использовать и т.д. Гораздо меньше внимания уделяется более интересному вопросу: а сохраняет ли в таких условиях актуальность сам подход к структурированию кода, которому нас учили, если у той штуки, которая теперь пишет код, ограничена долговременная память, а также ограничено контекстное окно? Более того, агент зачастую должен добиваться прогресса по задаче, не имея «перед глазами» всей системы.

Ниже проанализированы различные архитектуры кода: TDD (разработка через тестирование), OOP (объектно-ориентированное программирование, ООП), FP (функциональное программирование, ФП), MVC (модель-представление-контроллер), MVVM (модель-представление-модель представления), микросервисы, событийно-ориентированная архитектура, CQRS (раздельная обработка команд и запросов), гексагональная архитектура, разработка через поведение (BDD), предметно-ориентированное проектирование (DDD). Они отсортированы по показателю прикладной полезности в условиях, когда программирует не человек, а агент.

История о том, как боль с потерянными компонентами и слетевшими токенами в Figma превратилась в собственный плагин для аудита дизайн-системы.

Как только AI‑агенты начинают участвовать в разработке, быстро выясняется неприятная вещь: проблема не в генерации кода, а в управлении смыслом изменений.

В статье рассказываю, как я перестроил процесс проектирования фич через связку:

— чата с агентом бизнес‑аналитиком;
 — графовой модели изменений;
 — MCP‑доступа к модели;
 — агентского бутстрапа;
 — формализованного техпроцесса.

На примере разработки агентской памяти показываю, как User Story превращается в граф ролей, целей, мотивов, API и зависимостей, а агент перестаёт быть «чатиком сбоку» и становится участником инженерного процесса.

Это не история про «ИИ пишет код».
Это история про то, как инженерное знание начинает работать как код.

Привет всем, на связи снова Дарья Борисова, системный аналитик из ПСБ. Продолжаю развеивать мифы о REST API. Если вы пропустили первую и вторую часть, то советую заглянуть туда: ведь мы уже разобрали некоторые заблуждения о природе REST. Сегодня мы разберем нюансы транспортных и бизнес-ошибок, погрузимся в кеширование и узнаем, действительно ли REST должен быть прокси для базы данных.

Переходите под кат, начинаем!

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья — продолжение предыдущей: Мой справочник по Feature-Sliced Design. На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD — архитектурной методологии для проектирования фронтенд-приложений.

В конце статьи есть ссылки на другие подходы к организации файловой структуры фронтенд-приложений.

Air Canada проиграла суд за слова чат-бота. Дилер Chevrolet «продал» Tahoe за доллар. Корень один: LLM одновременно решает что сказать и как. Под давлением точность проигрывает беглости. Разбор паттерна, который это чинит.

Современная разработка программного обеспечения по‑прежнему сталкивается с устойчивым разрывом между тем, как человек описывает намерение системы, и тем, как это намерение затем становится машинно‑исполняемой логикой. Требования, проектные решения, ограничения, бизнес‑правила и примеры ожидаемого поведения чаще всего существуют отдельно от исходного кода. Даже при достаточно дисциплинированном процессе разработки документация со временем может терять связь с реализацией, тогда как код остаётся исполняемым, но не всегда выражает предметный смысл системы в явном и проверяемом виде.

Классическим ответом на эту проблему стали формальные методы и формальные языки спецификаций. Они позволяют описывать систему строго, проверяемо и пригодно для анализа. Однако такая строгость требует от разработчика специальной подготовки и готовности работать в заранее заданной формальной системе. В повседневной инженерной практике значительная часть знания о системе сначала фиксируется не в коде, а в текстовых требованиях, заметках, таблицах, примерах, обсуждениях и проектных пояснениях. Перевод этого материала в формальный язык требует отдельного усилия и потому далеко не всегда становится частью реального рабочего процесса.

Другой ответ связан с развитием больших языковых моделей. Они сделали практически значимым сценарий, при котором код может быть получен непосредственно из естественно‑языкового описания. Такой подход полезен как средство поддержки разработчика, ускорения прототипирования и получения черновых реализаций. Однако в роли компилятора он остаётся проблемным. Вероятностная модель может дать работоспособный фрагмент кода, но такой результат трудно рассматривать как воспроизводимый, проверяемый и объяснимый переход от спецификации к реализации.

В статье рассмотрим, почему эволюционная архитектура и модульный монолит превосходят современные архитектурные подходы. Обсудим, в каких случаях стоит отказаться от микросервисов, как документировать архитектурные решения с помощью ADR и какие методы помогают спасать проекты.

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».

Третья статья из серии. Предыдущие: манифест до первой строчки кода и итерация 0 — скелет и первый вебхук.

Я обещал публиковать честно: и где всё идёт по плану, и где разбиваешься о реальность. Вот статья про и то, и другое.

Три итерации — ровно. Четвёртая — ветка feat/iter-4 удалена, откат на main. Причина не в технических проблемах. Причина в том, что я наконец честно посмотрел на то, что построил, и понял: модель диалога слабая.

Про кастомные Query Builders в Laravel написано уже немало, но на практике мало что меняется. В 2026 году в проектах по-прежнему можно встретить запросы, разбросанные по всему коду - в контроллерах, сервисах и моделях. В такой структуре быстро теряется понимание, что происходит и где искать нужную логику.

Думал, зайду в крипту и буду просто дёргать API блокчейна. Не вышло.

Захожу в проект. Стек: FastAPI, PostgreSQL, Redis как Celery broker, Celery workers, Docker, Web3. Стартап на хайпе, деньги реальные, архитектура собрана на коленке. Смотрю на архитектуру платёжного процессинга и первая мысль: ребята, вы серьёзно? Финансовые операции с реальными деньгами, без idempotency вообще, Redis как брокер без persistence, Web3.py синхронные вызовы внутри Celery тасков.

Разговор был короткий: задача такая, чини что есть. Сроки горели.

Меня зовут Александр Сахаров, я директор по партнерствам в компании Диасофт. И тезис, с которого начну, довольно дерзкий: старый айтишный треугольник «быстро, дешево, качественно, выберите два» в 2026 году можно закрывать. Правда, с одним условием, о котором почему-то  практически не говорят.

На днях мы собрались с коллегами обсудить мифы вокруг искусственного интеллекта. Поговорили про AGI и массовые увольнения из-за внедрения ИИ, но с определенной долей скепсиса. И вот почему. Дело в том, что по свежим данным 56 процентов CIO в мире за последний год не получили от ИИ ни роста выручки, ни снижения затрат. Удивлены?

Привет, Хабр!

На протяжении нескольких лет одной из наиболее популярных и важных книг в нашем арсенале остаётся книга Влада Хононова «Изучаем DDD предметно‑ориентированное проектирование». Мы регулярно контактируем с Владом и надеемся, что вскоре сможем опубликовать здесь и развёрнутое интервью с ним. А сегодня хотим предложить вам подробный и несколько критический обзор его книги, найденный в одном англоязычном блоге. Автор статьи не скрывает, что книга Влада не вполне подошла под конкретные задачи, которые автор надеялся с её помощью решить и упростить. Но при этом он настолько толково описывает саму парадигму, а также как именно и для каких целей её лучше использовать, что мы сочли её отличной и честной рекламой нашего бестселлера. Далее — авторский обзор от сеньора Факундо Оланы из Аргентины.

Статья четвертая из серии. Были исследование, личная история, продуктовый инсайт. Здесь будет продукт. Публикую манифест до того, как написана первая строчка кода — чтобы потом было честно сравнить, где я прав, а где разбился о реальность.

При проектировании многослойной архитектуры приложения одной из главных задач является формирование набора моделей данных каждого слоя и определение порядка взаимодействия моделей данных между собой. Под взаимодействием понимаются потоки данных, передаваемые из одной модели данных в другую. В общем случае взаимодействие между моделями данных двунаправленное.

Рассмотрим модель данных application model, которая потребуется в дальнейшем изложении и которая используется в паттерне CQRS.

Реализация архитектурного паттерна CQRS, используемого в приложении для функционала application logic, представляет собой набор классов наследников базовых классов QueryHandler / CommandHandler и набор классов данных, которые являются наследниками базовых классов Query / Command. Классы наследники Query / Command представляют собой модель данных application logic. Такую модель данных логично назвать application model.

Используя application model и другие известные модели данных слоёв приложения можно построить полную схему моделей данных многослойной архитектуры приложения.

Всем привет. В последнее время в одной профессиональной соцсети я все чаще стал натыкаться на посты, связанные с dotnet C# тематикой. К сожалению, эти посты в большинстве своем не содержат полезной информации. Скорее всего они создаются для охвата аудитории с целью привлечения трафика на сторонние платформы по продаже курсов для разработчиков. По-моему, этот способ называется "воронка продаж" (поправьте, если я ошибаюсь). Как правило, эти посты затрагивают какую-то не очень сложную тему и содержат примеры кода. Недавно мне попался очередной пост, в котором автор пытался показать пример использования новой фичи labeled break and continue. Это новая фича, которую добавили в C# 15 (dotnet 11). На момент написания она была принята в Working Set, но финального релиза ещё не было. Ниже код, похожий на оригинал из поста. Он разделен на 2 секции: "как делали раньше" и "как сделать используя новый подход":

Стандартный способ: