Автор: Listen IT · Listen IT

Видео Listen IT, 15 минут. Event Storming — воркшоп-техника, разработанная Альберто Брандолини. Сессия начинается не с рисования схем, а с вопроса: какие события происходят в системе? И именно этот порядок меняет всё.

Типичная архитектурная сессия выглядит так: техлид рисует диаграмму, остальные кивают или спорят о деталях реализации. Знание о домене остаётся в головах у бизнес-экспертов и не попадает в код. Event Storming переворачивает процесс: на стену клеятся оранжевые стикеры с доменными событиями («заказ размещён», «платёж подтверждён», «склад уведомлён»), и сразу становится видно, где у команды нет общего языка — кто-то называет одно и то же по-разному, кто-то предполагает событие, которого на самом деле не существует. Пробелы в знании домена вскрываются за часы, а не за месяцы.

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

Из этого можно взять в…

Автор: Папочка Разработки · Папочка Разработки

Канал «Папочка Разработки», 20 минут. CQRS (Command Query Responsibility Segregation) — паттерн с устойчивой репутацией «понятного на собесе, но непонятного в коде». Видео разбирает, почему так происходит.

Распространённое понимание CQRS: разделить код на команды (пишут данные) и запросы (читают данные), сложить по разным папкам, добавить Handler для каждого — и считать, что CQRS внедрён. Это не CQRS, это просто именование. Настоящий паттерн — про разделение моделей: модель записи оптимизирована для инвариантов и бизнес-правил, модель чтения — для отображения данных в том виде, в котором их хочет видеть клиент. Когда модели разделены по-настоящему, появляется возможность масштабировать чтение и запись независимо, использовать разные хранилища, денормализовать read-side для производительности. Без разделения моделей это просто организация кода, а не архитектурный паттерн.

Кому смотреть: разработчикам, которые используют или планируют CQRS и хотят убедиться, что…

Автор: Юрий Самсонов · JUG.ru

Юрий Самсонов — разработчик из Яндекса. Доклад на JPoint 2023 — не обзор GraphQL и не агитация за его повсеместное использование, а конкретный опыт внедрения: что сломалось, что не ожидали, как вышли.

REST-эндпоинты имеют предсказуемую проблему роста: по мере того как клиентов становится больше, у каждого появляются свои требования к форме данных. Один клиент хочет вложенный объект, другой — плоский список. Появляются параметры вроде ?include=user,tags,comments, эндпоинты обрастают опциями, и в какой-то момент backend-разработчик обнаруживает, что его работа — это в основном добавление новых вариаций существующих эндпоинтов под нужды клиентов. GraphQL переворачивает эту ответственность: клиент сам описывает, какие данные ему нужны, и получает ровно их — без over-fetching и under-fetching. Самсонов честно рассказывает о том, что эта свобода стоит: N+1 проблемы, сложность с кешированием, отладка запросов, которые клиент сформировал сам.

Кому смотреть: backend-разработчикам, у которых…

Автор: Listen IT · Listen IT

Видео Listen IT, 7 минут. BFF (Backend-for-Frontend) и API Gateway — два паттерна, которые часто упоминают вместе и так же часто смешивают в один. Это разные решения разных проблем.

API Gateway — единая точка входа для всех клиентов: аутентификация, rate limiting, роутинг запросов к нужным сервисам. Он не знает о специфике клиента — будь то мобильное приложение, веб или сторонний партнёр, все получают одинаковый интерфейс. BFF — другое: отдельный backend, специально заточенный под нужды конкретного типа клиента. Мобильному приложению нужны агрегированные данные в компактном формате, чтобы не делать десять запросов там, где один. Веб-интерфейсу нужны другие данные в другой структуре. BFF решает это не изменением общего API, а созданием специализированного слоя для каждого клиента. Разделение полезное — пока не начинаешь дублировать логику между BFF для web и BFF для mobile.

Кому смотреть: разработчикам и архитекторам, проектирующим API для нескольких типов клиентов — мобильного…

Автор: Максим Денушев (Точка) · Golang Channel

Максим Денушев работает в банке Точка. Доклад с GolangConf 2024, 31 минута. API Gateway — компонент, через который проходит весь трафик платформы. Переписать его — значит заменить двигатель у летящего самолёта: система должна оставаться доступной, а пользователи не должны заметить, что что-то происходит.

Главная сложность такой задачи не техническая, а операционная. Выбрать новый стек и написать код — это меньшая часть работы. Настоящий вызов — как организовать переход так, чтобы в каждый момент времени система работала корректно для всех клиентов. Денушев разбирает подход, который команда применила: постепенное перемещение трафика через новый Gateway параллельно со старым, профилирование под реальной нагрузкой, работа с проблемами обратной совместимости, которые обнаруживаются только когда через систему идут реальные данные. Это не история успеха без шрамов — доклад честный о том, с какими проблемами они столкнулись и что их не предусмотрели заранее.

Кому смотреть:…

Автор: Listen IT · Listen IT

Видео Listen IT, 15 минут. C4 — архитектурная нотация, созданная Саймоном Брауном как ответ на две типичные проблемы: диаграммы, которые непонятны никому кроме их автора, и схемы, которые устаревают быстрее, чем успевают быть прочитанными.

Большинство архитектурных диаграмм страдают одним и тем же пороком: непонятно, для кого они нарисованы. Схема, адресованная топ-менеджменту, содержит детали реализации, интересные только разработчикам. Схема для разработчиков — слишком крупная, чтобы из неё понять что-то конкретное. C4 решает это через явную иерархию четырёх уровней: Context (система и её окружение для нетехнической аудитории), Container (приложения и базы данных, из которых состоит система), Component (модули внутри одного контейнера) и Code (диаграммы классов, нужны редко). Каждый уровень отвечает на разный вопрос и адресован разной аудитории — и это не абстрактная теория, а конкретный инструмент против диаграмм, которые не читает никто.

Кому смотреть: разработчикам и техлидам,…

Автор: Владислав Танков · Podlodka Podcast

Владислав Танков — директор по AI в JetBrains. Это второй его выпуск на Podlodka (#452): первый (#444) был про внутреннее устройство LLM на уровне трансформеров и аттеншенов. Этот — про то, что происходит, когда модель нужно не просто запустить, а запустить в продакшне под реальной нагрузкой.

Большинство разговоров про LLM в продакшне сводятся к «берём OpenAI API и готово». Танков рассказывает про другой класс задач: когда API не подходит — из-за данных, задержки, стоимости или политики безопасности — и нужно думать об инфраструктуре самому. Локальный инференс vs облачный — это не просто вопрос цены, это вопрос контроля над latency, privacy и зависимостью от внешнего провайдера. В JetBrains этот выбор делается для каждого продукта отдельно, и критерии нетривиальны.

Кому смотреть: инженерам и архитекторам, которые строят или планируют строить продукты поверх LLM и хотят понять инфраструктурную сторону вопроса — не теорию трансформеров, а что конкретно потребляет память,…

Автор: Александр Данковцев · HighLoad++

Александр Данковцев — Lead Engineer команды Antimonolith в Авито. Команда занимается тем, что помогает сотням сервисов взаимодействовать друг с другом не хаотично, а по правилам. Доклад с HighLoad++ 2024 — про API Gateway как ключевой элемент этой архитектуры.

API Gateway — одно из тех решений, которые выглядят просто («просто обратный прокси с маршрутизацией»), пока вы не начинаете масштабировать. В Авито тысячи микросервисов, сотни команд и постоянно меняющиеся API. Данковцев рассказывает, как Gateway эволюционировал от простого роутера до полноценного инфраструктурного продукта: с собственным языком конфигурации, валидацией, rate limiting, auth-интеграцией и observability. Ключевая мысль: когда Gateway становится платформой, а не конфигом nginx, он начинает требовать того же инженерного внимания, что и любой другой продукт — владельца, versioning, обратной совместимости.

Кому смотреть: архитекторам и техлидам, которые строят или унаследовали API Gateway в системе с…

Автор: Александр Алексеев · Папочка Разработки

Александр Алексеев ведёт канал о .NET-разработке, где объясняет архитектурные концепции без академической перегруженности. Это видео — один из лучших русскоязычных входных точек в DDD: без Эванса на 500 страниц, но с сохранением сути.

Domain-Driven Design принято считать сложным — и чаще всего путают причину сложности. Дело не в паттернах: агрегаты, репозитории, value objects можно выучить за вечер. Настоящая сложность DDD в другом: он требует, чтобы разработчики говорили на одном языке с теми, кто понимает предметную область. Без этого единого языка — Ubiquitous Language в терминах Эванса — код отражает не бизнес-логику, а то, как разработчик её понял. В больших системах этот разрыв со временем становится главным источником багов и рефакторингов.

Александр разбирает, почему DDD особенно важен именно для сложных, долгоживущих систем и почему его не стоит тащить в простые CRUD-приложения — это отдельный тезис, который стоит услышать до того, как начинать внедрение.

Ко…

Автор: Сергей Константинов · SDCast

Сергей Константинов написал книгу «The API» — бесплатную, в открытом доступе, на русском и английском. До этого разрабатывал API в Яндекс.Картах. В подкасте разбирает то, что в этой теме обычно остаётся за кадром обычных туториалов.

Центральная идея, которую Константинов проводит через всю книгу: закон больших чисел работает против автора API. Если концепцию или сигнатуру вызова можно понять неправильно — её неизбежно будут понимать неправильно всё больше людей по мере роста популярности API. Поэтому нейминг в публичном API — это не вопрос стиля и не задача code review. Это архитектурное решение: каждое имя, вышедшее наружу, становится обязательством.

Отсюда — его подход к проектированию через пирамиду контекстов. Сначала — зачем вообще нужен этот API, какую задачу он решает. Потом — абстракции и ответственность сущностей. И только в конце — конкретная номенклатура. Потому что цена ошибки на разных уровнях сильно отличается: «если исправить плохое именование сравнительно…