В статье рассмотрим, почему эволюционная архитектура и модульный монолит превосходят современные архитектурные подходы. Обсудим, в каких случаях стоит отказаться от микросервисов, как документировать архитектурные решения с помощью 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 секции: "как делали раньше" и "как сделать используя новый подход":
Стандартный способ:
Привет! Меня зовут Марк Каширский, я работаю 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, для чего он нужен, почему я вообще продолжаю его развивать и куда хочу вести дальше.
