Компоненты инфраструктуры не должны изменяться после их создания. Изменения могут вноситься только путем повторного создания компонента (и любых зависимых компонентов) с новыми или измененными свойствами.
«Разделение ответственности на команды и запросы» (Command Query Responsibility Segregation, CQRS). Идея CQRS заключается в том, что способ, которым мы запрашиваем системы, и способ хранения данных не обязательно должны быть одинаковыми.
Интерфейс хранилища событий должен поддерживать три основные функции:
• сохранять новые события в правильной последовательности, чтобы мы могли извлекать события в том порядке, в каком они были сохранены;
• уведомлять подписчиков, которые создают проекции, о новых интересующих их событиях, и поддерживать паттерн «Конкурирующие потребители» (https://oreil.ly/WZ9Ss);
• возвращать N событий определенного типа после события X для сверки, то есть для перерасчета на случай потери проекцией, возникновение угрозы или сомнений
Обратите внимание, что последовательность событий в сагах действительно имеет значение и требует особого внимания при конструировании. Шаги, которые труднее компенсировать, обычно лучше размещать ближе к концу транзакции
Саги (Sagas) впервые были описаны Гектором Гарсия-Молиной (https://oreil.ly/bIRr3) в 1987-м, задолго до появления современных распределенных систем, и позже популяризированы Клеменсом Вестерсом в его блоге в 2012-м (https://oreil.ly/f5cLI) как эффективное решение для распределенных систем
Когда распределенные данные только читаются, но не изменяются, как в контексте корпоративной аналитики, машинного обучения, аудита и т.д., общим решением является копирование наборов данных соответствующих микросервисов в общую область, которую обычно называют озером данных (data lake)
