Перейти к содержанию
Инженер следующего изменения

Оглавление

Владимир Синявский / Engineering Lead / Software Architect

Беру техническую ответственность там, где системе предстоит много изменений

12 лет проектирую и модернизирую backend-системы на .NET. Работал с платёжными контурами, распределёнными интеграциями и legacy в непрерывной эксплуатации.

Совмещаю архитектуру, hands-on разработку и техническое лидерство. Разбираю домен, провожу границы системы, делаю опорную реализацию и передаю команде понятный контекст.

Lead AI-native Engineer, Альфа-Лизинг, с октября 2025

Контакт Резюме PDF, откроется в новой вкладке

12 лет в backend engineering
Более 5 лет технического и командного лидерства

Система

Домен, жизненные циклы, интеграции, данные и границы ответственности.

Delivery

Путь до production, наблюдаемость, quality gates и безопасная эволюция legacy.

Команда

Ownership, развитие лидов и AI-инструменты с проверяемым результатом.

01

Почему я этим занимаюсь

В начале карьеры хорошая разработка для меня означала умение быстро писать качественный код.

Потом продукты выросли. Вместе с ними появились новые команды, интеграции и требования, а каждое следующее изменение стало затрагивать всё больше компонентов.

Архитектура стала ежедневной практикой. Она помогает заранее видеть последствия решений для следующих релизов.

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

02

Я начинаю с домена и ограничений. Технологии приходят позже

  1. 1 Понять предметную область

    Где проходят реальные границы домена и почему одни и те же слова значат разное?

  2. 2 Найти реальные ограничения

    Я смотрю на технические ограничения вместе с продуктовыми и организационными.

  3. 3 Смоделировать домен

    Модель нужна для решений. Простого описания текущего кода недостаточно.

  4. 4 Спроектировать границы

    Ответственность компонентов и команд должна оставаться понятной при росте.

  5. 5 Выбрать технологии

    Сначала я разбираюсь с задачей и ограничениями, потом выбираю технологию.

  6. 6 Вывести на прод

    После релиза видно, как решение ведёт себя под нагрузкой, с реальными интеграциями и обратной связью.

  7. 7 Наблюдать и развивать

    Новые факты меняют архитектуру. Это нормальная часть её жизни.

03

Чем я занимаюсь

Новая платформа

Спроектировать продуктовую систему, собрать техническую основу и вывести MVP на прод.

Legacy без остановки

Развивать работающую систему постепенно, сохраняя бизнес-процессы и совместимость.

Команда и ответственность

Распределить технические решения между инженерами и сохранить понятность системы для команды.

AI-native Engineering

Проверять AI-подходы в реальной работе и оставлять то, что действительно помогает инженерам.

04

Домены меняются. Классы инженерных проблем повторяются

Точки слева направо: Payments, Travel, EdTech / Legacy, AI-native.

Выбранная задача

Сложная предметная область

AI-native

Задача была второстепенной для этого домена.

Выбранная задача

Внешние интеграции

Выбранная задача

Асинхронность и неопределённость

EdTech / Legacy

Задача была второстепенной для этого домена.

Выбранная задача

Эволюция без остановки

AI-native

Задача была второстепенной для этого домена.

Выбранная задача

Надёжность и наблюдаемость

Выбранная задача

Инженерная среда

21 из 24 пересечений подтверждено конкретными проектами. Для трёх оставшихся эта задача была второстепенной в домене.

"Эволюция без остановки" встречалась в legacy-биллинге, работающих travel-сервисах и при постепенной замене Rails на .NET.

05

Проекты, где я с этим работал

CASE-002

Travel & Business Travel

В travel-домене внешне простое "найти и забронировать" превращалось в агрегацию нескольких GDS и разные жизненные циклы брони, оплаты и взаиморасчётов.

Контекст. RuTrip держал около 300 rps. В продукте были 40 фильтров, 4 сценария бронирования, 3 способа оплаты и 2 вида взаиморасчётов с GDS.

Что сделал. Работал над агрегацией поиска и бронирования, Customer Journey Map и общим языком с продактом. Архитектуру постепенно переводили на vertical slices.

Результат. Время поисковой выдачи сократилось с 20-30 до 6-8 секунд. Позже в business travel я работал с внешними GDS и критичными корпоративными системами, которыми пользовались 300+ сотрудников.

CASE-003

Evolutionary Legacy Modernization

Нестабильный Rails API платформы с 20 000 активных пользователей нельзя было остановить и переписать целиком.

Контекст. Работающий продукт зависел от нестабильного Ruby on Rails API, а миграцию нужно было провести без остановки клиентских приложений.

Что сделал. Собрал команду из четырёх backend-инженеров. Мы постепенно замещали маршруты через Strangler Fig и параллельно переносили данные.

Результат. Клиентские приложения переходили на новый API бесшовно. Мы выпускали его по частям и уложились в жёсткие сроки, не останавливая продукт.

CASE-004

Engineering Organization

В инвестиционном EdTech-продукте команда выросла с 5 до 15 человек и разделилась на две.

Контекст. Команда выросла с 5 до 15 человек и разделилась на две. Следующим ограничением стала концентрация технических решений у одного лидера.

Что сделал. Занимался наймом, 1:1, ИПР и делегированием. В команде появились DDD, Event Storming, взаимное ревью, тестирование и DevOps.

Результат. Три инженера выросли до тимлидов. Каждая команда получила свой контур технической ответственности.

CASE-005

AI-native Engineering

Сейчас я проверяю в реальной работе инструкции для AI-агентов и процесс разработки с ними. Подход ещё формируется.

Контекст. Нужно было ускорить сложную интеграционную разработку и работу с legacy, оставляя инженерные решения за человеком.

Что сделал. Собрал 20+ инструкций для AI-агентов (agent skills), настроил их версионирование и доставку, подключил к работе бэкенд-команд и обучил коллег.

Результат. В одиночку собрал MVP омниканального колл-центра за 4 месяца. За 5 недель перенёс другой legacy-проект с PHP на .NET / React, используя AI-инструменты.

Active development

Открытый проект

OSS-001

Travel Platform

Открытый проект, где видны моделирование домена, архитектурные решения и организация кода. Сейчас готов бэкенд Flights M1: модульный монолит с DDD, интеграции с поставщиками авиаконтента, устойчивость, наблюдаемость и отдельный AI-сервис.

Следующие этапы: Hotels, Rail, Trip Planning и ядро AI-сервиса.

Открыть репозиторий
06

Несколько наблюдений из практики

Хорошая архитектура нужна пятому году жизни продукта сильнее, чем первому релизу.

Самые сложные проблемы часто начинаются с разного понимания предметной области.

Команду и инженерные процессы тоже приходится проектировать.

AI меняет работу сильных инженеров, но ответственность за решения остаётся у человека.

07

Почему существует этот сайт

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

Теперь я собираю такие истории сам.

Архитектура

Проектирование, которое работает после первого релиза

Длинные разборы решений, ограничений и цены изменений.

 Практика

Статьи на Хабре

DDD, distributed systems, legacy и инженерная работа с AI.

 Исследования

Интерактивные инженерные разборы

Как порядок решений влияет на стоимость и устройство системы.

В Telegram: наблюдения из инженерной практики, продолжения статей и эксперименты с AI в работе синьора и техлида.

08

Если хотите обсудить похожую систему или решение, напишите

Email siniavsky.vladimir@gmail.com Telegram @vladimir_sva GitHub svasorcery Блог blog.vsinyavsky.ru Сайт vsinyavsky.ru Документ Резюме PDF, откроется в новой вкладке

Буду обновлять эту страницу вместе с проектами и собственным опытом.