DDD и Event Driven архитектура
Начинаем моделирование предметной области по заданию для проекта аукциона. Рассмотрим домен и поддомены для нашего бизнеса с точки зрения DDD. Перейдём на Event Driven архитектуру для проведения сложных бизнес-процессов в системе слабосвязанных модулей. Поговорим про сложности моделирования и познакомимся с практикой Event Storming для построения цепочек команд и событий:
- 00:00:55 - Подобласти или поддомены
- 00:02:44 - Единый язык всех сотрудников
- 00:03:58 - Ограниченные контексты языка
- 00:04:59 - Важность коммуникаций
- 00:06:38 - Единый формат диаграмм
- 00:08:41 - Модули проекта
- 00:09:38 - Модульный монолит и микросервисы
- 00:12:52 - Устройство модуля аутентификации
- 00:18:00 - Минимизация связей
- 00:19:45 - Выполнение сложных процессов
- 00:22:34 - Транзакция в монолите
- 00:25:59 - Множественные вызовы из контроллера
- 00:28:11 - Неудобные связи
- 00:29:01 - Уведомление о событиях
- 00:31:11 - Слушатели событий
- 00:32:22 - Цепочки команд и событий
- 00:36:21 - Event Driven архитектура
- 00:39:24 - Надёжность получения и и повторы
- 00:42:37 - Удобство диаграммы событий
- 00:45:42 - Кто должен рисовать
- 00:47:18 - Сложности процесса проектирования
- 00:48:48 - Практика Event Storming
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо!
Огонь.
Дмитрий, подскажите пожалуйста.
Если у нас есть домен отвечающий за город пользователя. Есть команда Command\SetCurrentCity
Далее остальные модули использую текущий город пользователя.
Получение текущего города пользователя будет GetCurrentCity, будет Command или Query ?
Модуль «город пользователя», не имеет никакого контекста, следовательно не может быть модулем. Объясню. Город фактического место нахождения человека может быть один, город для поиска работы может быть другой, город для размещения объявлений третий, город для заказов четвёртый, город для расчёта налогов пятый. Суть, думаю, уловили.
Так же помимо самого города пользователя может требоваться и другие бизнес правила связанные с городом. Например, для договора достаточно указать название города, а вот для расчёта доставки пиццы требуется не только город, но и много чего ещё. Так же и для оценки стоимости авто в разных городах могут отличаться. В общем, в зависимости от контекста город может иметь разные требования. Так же он может где-то быть Value Object, а где-то Entity.
Это было отступление. Теперь о вашем вопросе.
Command - это мутация, команда. Она никогда не возвращает результат. Хотя есть компромисс в виде ID.
Query - это запрос. Она всегда что-то запрашивает, но ничего не мутирует (не изменяет) и получает результат запроса.
Соотвественно GetCurrentCity всегда Query.
Спасибо!
Или войти через: