Сохранение согласованности между агрегатами

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

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

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

На основе этой информации вы можете создать три агрегата: «Корова», «Запас» и «Заказ».

Примечание: Cow - паршивая совокупность - если предположить, что мы говорим о настоящих в мире поедающих травяных коровах. Да, это сущность, но она находится вне влияния модели. Если модель говорит, что корова пуста, а корова говорит, что она полна молока, корова права.

Точно так же, если коровы настоящие, то большая часть вашего поголовья также настоящая. Если модель говорит, что есть семь полных канистр молока, а фермер считает шесть, то шесть - правильный ответ.

Агрегаты - это информационные ресурсы.

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

Важно понимать, что «сразу»; вы здесь, пользователь (покупатель?) там. Связь имеет определенную задержку, а это означает, что информация, которую вы отправляете покупателю, уже устарела, когда она поступает. (Технически он уже устарел на момент отправки.)

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

В вашем примере параллельной обработки это будет выглядеть как две команды для резервирования 130 литров молока, работающих одновременно с агрегатом запаса, имеющим 150 литров молока. Используя оптимистичный параллелизм, обе команды обнаружат, что молока достаточно для удовлетворения заказа, и попытаются обновить книгу записей. Однако это обновление сериализуется - подумайте о транзакции или сравните и поменяйте местами - поэтому одна из команд выполняется успешно, а другая вместо этого получает исключение одновременной модификации. Таким образом, эта вторая команда пытается еще раз, перезагружая ложу в ее новом состоянии. На этот раз он обнаруживает, что имеющихся запасов недостаточно, и действует соответствующим образом (перемещает заказ в список ожидания, уведомляет покупателя об ожидаемой дате выполнения и т. Д.).

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

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

Я пойду в другом направлении и скажу: не обязательно. Вы всегда собираетесь требовать согласованности между агрегатами в какой-то момент времени. Вопрос только в том, когда. Вы можете обнаружить, что в некоторых ситуациях сталкиваетесь с политикой. Мне пришлось реализовать 100% немедленную согласованность между целой кучей агрегатов просто потому, что я получил указание сделать это от тех, кто владеет строками кошелька. В идеальном мире мы были бы свободны выбирать. Но в моем реальном мире вы можете поспорить, что мы проиграем. В любом случае, если отбросить лирику, безусловно, можно уйти от немедленной согласованности.

Изменение более чем одного агрегата в транзакции - это еще не конец света, но если вы можете этого избежать, вам, безусловно, следует этого избежать. Как и следовало ожидать, это связано с небольшими накладными расходами.

В вашем примере вы можете проверить уровни запасов, но, как уже отмечалось, одновременное чтение приводит к вводящей в заблуждение информации. Однако вы можете разместить заказ и еще до того, как вы начнете процесс, вы можете «зарезервировать» количество, используя то, что станет идентификатором вашего менеджера процесса и вашим общим «идентификатором корреляции». если вы не можете зарезервировать запас, вы можете отказаться от заказа. Однако вам придется зарезервировать несколько товаров для определенных заказов с более чем одним товаром.

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

Просто мысли :)