Провели большой практический стрим про разделение на модули и микросервисы
Задонатить и смотреть →
Открой безлимитный доступ к 100+ полезных скринкастов и получай скидки на все предстоящие мероприятия

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
Комментарии (4)
Руслан

Спасибо!

Ответить
Андрей

Огонь.

Дмитрий, подскажите пожалуйста.

Если у нас есть домен отвечающий за город пользователя. Есть команда Command\SetCurrentCity

Далее остальные модули использую текущий город пользователя.

Получение текущего города пользователя будет GetCurrentCity, будет Command или Query ?

Ответить
Максим

Модуль «город пользователя», не имеет никакого контекста, следовательно не может быть модулем. Объясню. Город фактического место нахождения человека может быть один, город для поиска работы может быть другой, город для размещения объявлений третий, город для заказов четвёртый, город для расчёта налогов пятый. Суть, думаю, уловили.

Так же помимо самого города пользователя может требоваться и другие бизнес правила связанные с городом. Например, для договора достаточно указать название города, а вот для расчёта доставки пиццы требуется не только город, но и много чего ещё. Так же и для оценки стоимости авто в разных городах могут отличаться. В общем, в зависимости от контекста город может иметь разные требования. Так же он может где-то быть Value Object, а где-то Entity.

Это было отступление. Теперь о вашем вопросе.

Command - это мутация, команда. Она никогда не возвращает результат. Хотя есть компромисс в виде ID.

Query - это запрос. Она всегда что-то запрашивает, но ничего не мутирует (не изменяет) и получает результат запроса.

Соотвественно GetCurrentCity всегда Query.

Ответить
B

Спасибо!

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu
  • 1DDD и Event Driven архитектура
  • 2Big Picture: Потоки событий Скоро
  • 3Process Modelling: Команды и политики Скоро
  • 4Software Design: Агрегаты и контексты Скоро