Первый шаг — сбор правильных людей в комнате (или в Zoom). Для успеха Event Storming при импортозамещении критически важно участие не только архитекторов и разработчиков, но и бизнес-аналитиков, экспертов предметной области (например, специалистов по логистике, финансам), а также представителей отдела информационной безопасности и юристов. Последние особенно важны для понимания новых ограничений и требований (законодательство о данных, санкционные риски).
Начинаем с событий (Domain Events) — фактов в прошлом, которые имеют значение для бизнеса. В контексте импортозамещения это могут быть события вроде «Поставщик из "недружественной" страны приостановил контракт», «Найден отечественный аналог компонента X», «Получено одобрение регулятора на использование криптографии Y». Эти события наклеиваются на оранжевых стикерах. Процесс помогает выявить «болевые точки» в текущей, возможно, завязанной на импортные решения, системе.
Далее вводим команды (Commands) — синие стикеры. Это действия, которые инициируют события. «Запустить процесс поиска альтернативного поставщика», «Инициировать миграцию данных с зарубежного SaaS на российский аналог», «Подписать соглашение о NDA с новым вендором». Здесь важно обсуждать, какие команды теперь требуют дополнительных проверок или согласований в новых реалиях.
Агрегаты (Aggregates) — желтые стикеры. Это кластеры объектов, которые обрабатывают команды и генерируют события. При импортозамещении агрегаты могут кардинально меняться. Например, агрегат «Закупки» теперь должен учитывать не только цену и качество, но и страну происхождения, наличие сертификатов ФСТЭК, валюту расчетов. Агрегат «Интеграция» должен быть перепроектирован для работы с отечественными API (например, ГИС Меркурий, ЕГАИС, система быстрых платежей ЦБ) вместо западных сервисов.
Особое внимание — выделению bounded context (ограниченных контекстов). Это ключ к созданию модульной, гибкой архитектуры. Вместо монолита, зависящего от импортных решений, мы проектируем контексты: «Управление цепочками поставок (с фокусом на ЕАЭС)», «Платежи и финансы (с интеграцией с НСПК)», «Безопасность и аудит (с отечественными средствами криптозащиты)». Между этими контекстами будут четкие контракты (API, события), что позволит заменять или обновлять их независимо.
На сессии обязательно появятся горячие точки (Hot Spots) — розовые стикеры. Это вопросы, риски и проблемы. «Как обеспечить ту же производительность с отечественным СУБД?», «Каковы юридические последствия хранения резервных копий за рубежом?», «Как интегрировать legacy-систему, которая работает только с Oracle?». Эти точки — основа для технико-экономического обоснования и плана миграции.
Результатом сессии Event Storming становится не просто схема, а общее понимание (Shared Understanding) новой, адаптированной к реалиям доменной модели. Эта модель становится путеводной звездой для:
- Выбора стека технологий (российские ОС (Astra Linux, ALT), СУБД (PostgresPro, Tarantool), фреймворки).
- Проектирования событийно-ориентированной архитектуры (Event-Driven Architecture), которая более отказоустойчива и адаптивна к изменениям.
- Формирования четких требований к вендорам отечественных решений.
Комментарии (6)