Панель мониторинга в дизайне, управляемом событиями

Что такое «ограниченный контекст» в этом контексте?

«и все они разделены с помощью служб обмена сообщениями». Это предположение, которое вы делаете из проекта, или вы это утверждаете? ...потому что компоненты могут быть тесно связаны, даже если между ними есть посредник.

Где сохраняется текущее состояние Order? (не говорите «в памяти» — это не средство сохранения). Разве ваша панель управления не может просто прочитать все это из производственной базы данных?

«Теперь, из-за асинхронного характера процесса, событие предыдущего состояния (например, PaymentProcessed) может попасть в контекст границы Dashboard после следующего состояния (например, ScheduledForDelivery)». - в этом случае ограничения этой проблемы (как вы ее описали) не могут быть удовлетворены, потому что вы только что сказали, что невозможно получить последнее состояние для Order.

@Dai Ну, это зависит от того, как вы определяете «последний». Вы можете рассуждать об этом так, что вы не разрешаете этот конкретный переход, который переводит Dashboard в предыдущее состояние. Это может быть достигнуто с использованием конечного автомата, например.

Состояние Order сохраняется в базе данных.

Компоненты должны быть отделены для других причин, стоящих за этой темой.

Да, я имел в виду нечто подобное. Есть ли обратная сторона такого подхода?

Ничего, о чем я могу думать.

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