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

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

На протяжении нескольких лет одной из наиболее популярных и важных книг в нашем арсенале остаётся книга Влада Хононова «Изучаем 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 секции: "как делали раньше" и "как сделать используя новый подход":

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

Привет! Меня зовут Марк Каширский, я работаю DS-инженером в команде LLM Авито. Создаю инструменты для разработчиков, чтобы им было легче и удобнее работать. В статье рассказываю, как мы автоматизировали процесс Code review при помощи больших языковых моделей.

Рефакторинг должен быть скучный и надежный. Надо держаться от искушения обновить библиотеку, починить баг, улучшить стиль. Под катом разбор почему именно такой путь сможет вытянуть тяжелый legacy рефакторинг, а шаг вправо и влево ведет к откату релиза.

В какой-то момент у нас один платеж начал жить с тремя курсами валют: checkout показывал сумму из Redis, payment-service ходил в API, а ledger писал проводку по снапшоту из Postgres. Расхождения были 2-5 тенге, иногда до 180. Разбираю, как это дебажили, какие костыли ставили и где DDD реально помог, без красивых схем.

Друзья, написал текст как пародию на переводные бравурные статьи про Artemis. Улыбки ради.

Представьте, что в наше время попал материал, написанный в 2126 году к столетию полета Arthemis II.

Сто лет назад, в апреле 2026 года, Artemis II облетела Луну. Тогда это подавали как начало новой эпохи. Теперь, с расстояния в век, видно другое: именно тогда началась не новая лунная гонка в духе Apollo, а длинная эпоха согласований, комиссий, переходных интерфейсов, «полезных для бюджета» архитектур и превращения красивых схем в то, что хотя бы не разваливается на глазах.

На дворе 2126 год. Я инженер NASA, почти сорок лет отдавший детской мечте о полёте к звёздам. Не историк и даже не человек, заставший Apollo. Про ту эпоху я знаю из учебников, внутренних обзоров, старых страниц NASA, кусков документации, которые спасли не архивисты, а чужая лень, и по мемуарам старых астронавтов, для которых космос ещё был временем, когда можно было подъехать к стартовому комплексу на своём Corvette, надеть скафандр, сесть в кресло и улететь к звёздам. Нам после ранней Artemis досталось уже другое наследство. Его мы разгребали десятилетиями. Поэтому позвольте говорить не от лица пресс-службы, а языком человека, которому потом пришлось видеть архитектуру изнутри.

Один вопрос про pgx — и три инструмента которые легко перепутать. QueryTracer не замена декоратору, декоратор не устарел, а выбор драйвера — неожиданно важное решение для observability. Какую комбинацию драйвера и обёртки выбрать — зависит от того что вы хотите видеть. В статье взгляд на комбинации драйверов и оболочек для анализа запросов в PostgreSQL. Разбираем на реальном проекте — с кодом, ошибками и выводами.

Лучше один раз разобраться, чем каждый раз сомневаться в выборе.

Продолжение первой статьи про взрослый вайб-код для тех разработчиков, которые уже перешли на тёмную сторону. Рассказ про фреймворк, который насильно заставляет писать ИИ хороший код с хорошими тестами.

Итак, вопреки утверждениям скептиков (среди которых не так давно был и я) ИИ-разработка с двух ног влетела в настоящую промышленную эксплуатацию, и мем уже совсем не тот: не джун теперь роняет прод, а нейросеть убивает статистику доступности гитхаба, амазона, Cloudflare и даже самой мекки вайб-кодинга — сервисов Anthropic и OpenAI. 

Вдохновился идеей OpenAI Harness Engineering и проверил на большом легаси проекте: можно ли отдать агенту всю реализацию, а человеку - постановку, тесты и ревью. Сотни файлов, зелёные тесты и два бага, которые нашли только руками. Про «согласованные ошибки», разные мнения и почему финал эксперимента открытый.

Привет! Никита Щербо на связи, backend-разработчик и тимлид в Битрикс24.

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

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

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

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

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

Дали мне недавно задачу написать тесты для одной CLI-тулзы. Это мне уже привычно и понимание, зачем тулза нужна, есть. Я только не знал, что меня ждёт в коде. Программист, писавший её, сделал гигантскую работу — претензий нет (не обижайся, пожалуйста, если читаешь это, но это стоит отдельной статьи). Там суммарно, наверно, порядка 30к строк кода написано. Нюанс в том, что, видимо, он раньше не писал на C#,

Так что тут я соберу для вас примеры, как нельзя писать и как стоит.

Почему ИИ-агенты усложняют понимание кода?
В этой статье разберем, как концепция Питера Наура «программирование как построение теории» объясняет скрытые риски использования LLM в разработке.

В данной статье, я расскажу о том, как возможно DDD сейчас обретает своё третье перерождение. Первое в 2003 году, по выходу книги, второе с выходом микросервисов и пониманием гранулярности, и последний - с развитием ИИ.

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

Когда проект молодой, писать «всё в одном классе» кажется быстрее. Создать отдельный интерфейс, вынести слой — это же лишняя минута! Но эта минута потом стоит часов: код невозможно покрыть тестами, замена ORM превращается в переписывание бизнес-логики, а новый человек в команде тратит день только на то, чтобы понять, где в методе заканчивается выборка из базы и начинается бизнес-правило.

Эти антипаттерны не привязаны к языку программирования — они встречаются и в Java, и в Go, и в Python. Примеры покажу на C#/.NET, но суть та же для любого стека. Три конкретных случая из реальных проектов — и как их исправить.

14 ошибок TypeScript. Такой был результат моего первого промпта в ChatGPT, когда я попросил написать тесты для React-компонента.

Через несколько месяцев тот же запрос "напиши тесты" выполняет мультиагентный пайплайн из 7 AI-агентов. Он сам планирует тест-кейсы, пишет код, проверяет его по философии RTL, а потом намеренно ломает компонент, чтобы убедиться, что тесты не врут. 40+ компонентов уже прошли через него на проде.

Это история про путь между этими двумя точками. Без прикрас, с тупиками и неработающими подходами.