События домена и управление версиями без CQRS

Обычно вы ставите сообщения в очередь. Если они собираются в очередь, вы получите правильный заказ. Если вы хотите использовать что-то, что не поддерживает заказ с вашей служебной шиной, добавьте порядковый номер к своим событиям, чтобы другая сторона могла правильно их изменить. TCP делает это с 1981 года. http://www.ietf.org/rfc/rfc793.txt :)

К сожалению: я только что заметил, что в вашем примере на самом деле вы использовали две разные задачи (имя клиента, а затем адрес клиента). Конечно, это не проблема, поскольку порядок на самом деле не имеет значения. Но я оставлю свой ответ на тот случай, если вы намеревались получить два одинаковых типа изменений.

Как всегда, на ум приходит пара вопросов / проблем:

Во-первых, в вашем примере не требуется, чтобы конечная точка выходила из строя, поскольку 2 пользователя могут обновлять адрес одновременно, а порядок обработки может быть случайным. Таким образом, возникает вопрос, какой адрес является правильным. Поэтому для решения этого требуется немного больше анализа. С одной стороны, я думаю, мы могли бы предположить, что клиент не будет перемещаться так часто, чтобы 2 пользователя обновляли адрес одновременно (или даже рядом с ним) --- :)

Даже в этом случае, возможно, первый адрес правильный.

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

Вам действительно не следует доводить это до технического уровня, чтобы попытаться решить эту проблему, а лучше посмотреть на последствия для процесса / бизнеса.

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

Аналогичная проблема с NServiceBus обсуждается здесь. OP предлагает использовать IBus.HandleCurrentMessageLater () для вращения до прибытия другого сообщения. Это может сработать, но может быть проблематичным, поскольку вы никогда не знаете, сколько времени вам придется ждать.

Более сложным вариантом было бы использование саги, которая будет ждать, пока не появятся все сообщения, ведущие к определенной версии. В этом случае упорядочение выполняется на основе версии и возможно только в том случае, если все изменения в агрегированной версии публикуются в другом BC. Предположим, что Сообщение 1 работает с версией 2 агрегата. Затем он увеличивает версию агрегата и публикует событие, указывающее, что оно работало с версией 2. Сообщение 2 работает с версией 3 агрегата и публикует событие, указывающее, что оно работало с версией 3. Когда конечная точка NServiceBus в другом BC получает Сообщение 2 перед Сообщением 1, он знает, что последнее полученное сообщение работало с версией 1 агрегата, поэтому ему нужно сообщение, которое работало с версией 2. Он запустит сагу, которая ожидает следующего сообщения. Как только он получит Сообщение 1, сага применит Сообщение 1, а затем Сообщение 2 и освободит состояние саги. Если использование версии для секвенирования неприемлемо, можно использовать другую стратегию секвенирования.

Согласно этому вы должны спросить себя:

Как повлияет на бизнес неудача?

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