Сегодня на TechLeadConf после моего выступления был вопрос — что делать, если приходится часто менять сервисы (примерно так). Вопрос касался Event Storming, — как часто корректировать модель, стратегический дизайн, как часто проводить периодические шторминги? Короткий ответ — в зависимости от частоты изменений предметной области. Высокая динамика изменений? Проводим чаще. Предметная область относительно стабильна? Проводим реже. Главное — делать это регулярно. Почему? Потому, что если будем назначать встречи по пересмотру модели, то такие встречи будут происходить после чего? Именно) После появления проблем. Регулярность даёт возможность обнаружить проблемы до того, как они стали реальными. Если же на регулярные встречи чаще приходим с уже случившимися проблемами дизайна — есть смысл начать проводить такие встречи чаще. Скоро завершу оформление статьи по итогам выступления, а пока пример, когда пришлось склеить два микросервиса в один. Обычные дела) Для тех, кто любит сестру таланта, основная мысль: «When adding new functionality we should question whether our architecture still justifies itself. In this case, at the beginning it seemed that a ride and a prebook have a right to live as separate entities, and therefore have separate services and databases. As more requirements and features arrived, it became clear that the separation of services caused cumbersomeness.»