Антон Мусатов — о том, как строить архитектуру для миллиардных транзакций и зачем бизнесу нужен единый язык с разработчиками
Цифровая трансформация стала не модным словом, а необходимостью. Компании с миллиардными оборотами зависят от работы своих IT-систем: сбой может обернуться потерей клиентов, контрактов и репутации. Но как построить архитектуру так, чтобы она выдерживала десятки миллионов операций в день, позволяла развиваться бизнесу и не превращалась в «черный ящик» для новых сотрудников?
О том, как обновить крупнейшую в России платформу электронных торгов без остановки работы, чем российская альтернатива SAP отличается от западного аналога и почему документация иногда важнее кода, рассказывает Антон Мусатов — ведущий разработчик корпоративных систем, чьи решения используют Росатом, Металлоинвест, Русагро и более 200 крупных корпораций.
— Антон, вы руководили технической трансформацией крупнейшей в России платформы электронных торгов. Что это была за задача?
Антон Мусатов: Это проект, от которого зависела половина российского рынка электронных закупок. Компания обрабатывает сделки на сумму более 10 миллиардов долларов ежегодно, и при этом продолжал работать на архитектуре, разработанной много лет назад. Система была критически важна для тысяч компаний, и остановить её ради обновления мы просто не имели права.
Мы пошли по пути постепенной модернизации. Построили архитектуру так, чтобы новые модули можно было вводить без остановки бизнеса. Это похоже на операцию на открытом сердце — пациент должен продолжать жить и работать, пока хирурги меняют ключевые органы.
Результат: мы не только обновили систему, но и сделали ее удобнее для пользователей. Раньше новым сотрудникам требовался год, чтобы освоить работу на платформе. После трансформации — две недели.
— То есть архитектура напрямую влияет не только на программистов, но и на конечных пользователей?
Антон Мусатов: Именно так. Архитектура — это не абстрактный чертеж для айтишников. Она определяет, как быстро бизнес реагирует на изменения, сколько времени уходит на обучение сотрудников, насколько безопасно проходят транзакции.
Я всегда привожу пример: когда бизнес говорит «мы хотим выйти на новый рынок через три месяца», именно архитектура отвечает на вопрос — возможно ли это вообще.
— Вы участвовали и в создании российской альтернативы SAP. Удалось ли сделать полноценную замену?
Антон Мусатов: Мы исходили из принципа: не нужно копировать SAP «один в один». Наша задача была в том, чтобы дать бизнесу рабочий инструмент, который можно внедрить быстро и адаптировать под российские реалии.
Проект занял всего полтора года. Для сравнения: внедрение SAP в крупной корпорации может идти пять лет. Мы использовали сервисную архитектуру и подходы Domain-Driven Design. Они позволили разложить сложнейшую предметную область на отдельные модули, над которыми могли параллельно работать разные команды.
Главное отличие нового продукта — гибкость. Если SAP изначально рассчитан на универсальность и из-за этого иногда становится тяжелым и медленным, то наша система была создана с прицелом на конкретные потребности российских компаний.
— Вы много говорите про Domain-Driven Design. Для бизнеса это звучит как что-то очень техническое. В чём ценность подхода?
Антон Мусатов: DDD — это не столько про код, сколько про понимание. Бизнес и разработчики начинают говорить на одном языке. Это критически важно: если юрист называет процесс «заключение договора», а программист пишет в коде «contract finalize», между ними пропасть. В результате проект буксует.
DDD предлагает: договоритесь об общем языке (мы называем его Ubiquitous Language) и используйте его везде — в документации, обсуждениях, тестах, коде. Тогда ошибки и недопонимания сокращаются в разы.
Вторая ценность — изоляция бизнес-логики от технологий. Система должна описывать именно бизнес-процессы, а не тонуть в технических деталях. Это позволяет и через 10 лет быстро понять, что делает тот или иной модуль.
— Какие тактические приемы помогают реализовать такие принципы на практике?
Антон Мусатов: Тут есть целый набор решений.
- Слоистая архитектура. Она разделяет бизнес-логику, инфраструктуру и интерфейсы. Важно, чтобы зависимости шли только в одном направлении — сверху вниз. Это снижает сложность и делает систему устойчивой к изменениям.
- Внутренний API. Когда интеграции внутри компании формализованы и прозрачны, команда быстрее вносит изменения. Это дисциплинирует архитектуру и экономит время.
- Правильный выбор хранилища данных. Для финансовых операций нужны реляционные базы, для логов — документоориентированные, для социальных графов — графовые. Ошибка здесь может стоить катастрофических задержек.
- Разграничение сущностей и объектов-значений. Это базовое правило DDD, но оно позволяет избежать хаоса, когда бизнес-объекты начинают дублироваться или пересекаться.
— А какие ошибки вы чаще всего видите в проектах российских компаний?
Антон Мусатов: Первое — гонка за модой. Увидели, что кто-то использует условный Kubernetes или «крутую» NoSQL-базу, и тянут это в проект. А специалистов нет, команда не готова. В итоге вместо ускорения получаем провал.
Второе — отсутствие документации. Многие считают её второстепенной. Но без неё новые сотрудники будут месяцами разбираться в коде. Я часто предлагаю вести документацию прямо в Markdown, хранить в репозитории, использовать диаграммы PlantUML. Тогда она живёт вместе с проектом.
Третье — попытка автоматизировать всё и сразу. Нужно выделять ядро предметной области, ключевые процессы. Если пытаться «закодировать» весь бизнес одномоментно — проект обречен.
— Сейчас вы работаете в международной компании Digitail, создаете облачные решения для ветеринарных клиник по всему миру. Как этот опыт отличается от работы с российскими корпорациями?
Антон Мусатов: Отличается тем, что продукт глобальный. Мы должны учитывать десятки законодательств, языков, подходов к медицине. Но по сути задачи те же: сложная предметная область, высокая нагрузка, требования к надежности.
Что интересно: в клиниках ветеринар использует систему так же, как менеджер в корпорации — он должен быстро находить данные, назначать процедуры, вести аналитику. И если система зависает, страдают не бизнес-процессы, а живые животные. Поэтому требования к надежности и простоте ещё выше.
— Если подытожить: какой главный принцип вы бы назвали для архитектора систем?
Антон Мусатов: Для меня главный принцип звучит так: архитектура должна помогать бизнесу, а не мешать ему. Это означает, что система должна быть понятной, гибкой и живой. Она должна жить десятилетиями, а не ломаться через год.
И ещё: архитектор должен уметь разговаривать и с программистами, и с бизнесом. Иначе он рискует построить прекрасный «технический замок», который никому не нужен.
История Антона Мусатова показывает: архитектура корпоративных систем — это не только про технологии, но прежде всего про людей. Единый язык между бизнесом и разработчиками, прозрачные модели и гибкие архитектурные принципы позволяют не просто автоматизировать процессы, а реально менять эффективность бизнеса.
В условиях, когда на кону стоят миллиарды долларов и судьба ключевых отраслей, архитекторы становятся теми, кто отвечает за устойчивость будущего. И, как справедливо отмечает Антон, хорошая система — это та, которая помогает бизнесу жить и развиваться, а не мешает ему.
Василий Черный