Здравствуйте, Poul_Ko, Вы писали:
P_K>Пример совсем из пальца — новый заказ не может быть создан, если у клиента уже есть два неподтверждённых заказа. Но ведь второй заказ может создать параллельно несколько пользователей, в итоге заказов станет больше двух, что является нарушением требований. И тут уже решение "не дублировать данные" никак не лезет.
В данном конкретном примере, если 99.5% юзеров не смогут создать третий заказ, а у 0.5% третий заказ появится, то все это переживут. Реальный мир по определению многозадачный и асинхронный и современные системы не зря предпочитают eventual consistency.
Еще пример из той же оперы — от нас часто требуют 100% сохранность введенных данных. А когда в такую систему уже инвестировано много сил и средств, оказывается, что в случае необходимости данные за последние сутки девочки могут вбить из первичных документов.
Стоимость заказа — нарисовать в гуй мелкими буквами "предварительная стоимость, окончательная будет определена в момент подтверждения заказа". Сделать неподтвежденные заказы протухающими в течение, скажем, суток.
Возможно, все ваши проблемы просто из-за недостаточной квалификации или бесхребетности архитектора.
