Axon Framework — Как реализовать дизайн контекста Upstream — Downstream

введите описание изображения здесьИспользуя Axon, как реализовать восходящий и нисходящий DDD между доменом и поддоменом.

Как мы можем сделать так, чтобы заказ прослушивал события субдомена доставки.

https://axoniq.io/blog-overview/bounded-contexts-with-axon


person Prashant Shandilya    schedule 03.05.2019    source источник


Ответы (1)


Короткий ответ — с Saga, примерно так: https://github.com/idugalic/digital-restaurant/blob/master/drestaurant-libs/drestaurant-order/src/main/kotlin/com/drestaurant/order/domain/OrderSaga.kt#L104

Длинный ответ таков: обе службы предоставляют API обмена сообщениями (команды, на которые вы можете отправлять, запросы, на которые вы можете отправлять, события, на которые вы можете подписаться). Услуга заказа зависит от службы доставки в этом случае. Обе службы реализуют модели поддоменов (Order — это не весь домен, возможно, это может быть поддомен core / more important). Домен заказа отвечает за создание order и проверку этого заказа в процессе. Доставка отвечает за доставку заказа, и они называют это доставкой. В контексте доставки нас не интересуют детали заказа и его содержание, нас в основном интересует адрес доставки.

Сага Order, о которой я упоминал в предыдущем разделе, может обрабатывать событие com.drestaurant.courier.domain.api.CourierOrderDeliveredEvent из службы shipping/courier и вызывать команду в службе Order для обновления состояния агрегата Order. Важно отметить, что в этом примере мы совместно используем сообщения как классы в файле JAR. Вам следует рассмотреть возможность совместного использования/документирования только схемы сообщений (например, JSON) и иметь копию этих классов API в зависимых службах (никаких зависимостей от общих модулей/банок API других служб). Таким образом, вы полагаетесь на сериализацию сообщений, и у вас будет возможность иметь немного разные копии этих сообщений/классов в зависимости от служб (например, вам не нужно десериализовать все атрибуты сообщения на другой стороне — вы можете выбирать). Это обеспечит более независимое развертывание ваших сервисов, поскольку они никогда не используют совместно какие-либо модули/jar-файлы.

Я должен признать, что не всегда легко обсуждать концепции из DDD, и они всегда связаны с контекстом. Тем не менее, я надеюсь, что этот ответ прольет больше света на ваши вопросы. Заполните, чтобы обсудить эту тему дальше.

Лучший, Иван

person Ivan Dugalic    schedule 03.05.2019
comment
Понятно, сага - это ответ. Однако что, если эти домен-поддомен должны быть развернуты отдельно. Например, если требуется внедрить и развернуть заказ и отгрузку как две микрослужбы, им все равно нужно прослушивать зависимые события. - person Prashant Shandilya; 04.05.2019
comment
Да. Если требуется внедрить и развернуть заказ и отгрузку как два микросервиса, им все равно нужно прослушивать зависимые события! Сервер Axon может распространять эти события (в том числе команды и запросы) - person Ivan Dugalic; 04.05.2019
comment
Сделал POC для распределенной саги с весенними загрузочными приложениями для заказа и отгрузки. Реализована ShipmentSaga. Получение исключения ниже -WARN 13472 --- [nd-processor]-0] o.a.c.gateway.DefaultCommandGateway : Command 'com.techm.bm.api.cmd.RegisterShipmentForOrderPreparedCmd' resulted in org.axonframework.eventsourcing.IncompatibleAggregateException(Aggregate identifier must be non-null after applying an event. Make sure the aggregate identifier is initialized at the latest when handling the creation event.) Пожалуйста, предложите, что не так с кодом - gitlab.com/bm-cqrs /axon-kafka-distributed - person Prashant Shandilya; 15.05.2019
comment
Я предоставил MR в вашем репозитории: gitlab.com/bm -cqrs/axon-kafka-distrbuted/merge_requests/1/ С помощью этого improvements я смог успешно запустить ваши приложения. - person Ivan Dugalic; 19.05.2019