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

На самом деле, он тут у нас на местной маршрутке газелистом работает, а этот сайт я ему на мобиле показал, когда на рынок за селедкой ехал. ЛОЛ