Здравствуйте, scf, Вы писали:

scf>Здравствуйте, Poul_Ko, Вы писали:

P_K>>У клиента одно действие — создать новый неподтверждённый заказ. Этот заказ создаётся и болтается в системе пока его не подтвердят или не отменят. И пока он болтается неподтверждённый цена в нём всегда должна строго соответствовать цене из справочника.
P_K>>Вполне допустимо, что перед созданием нового неподтверждённого заказа на экране юзер видел одну цену, а после создания она стала другой.

scf>Я бы, на месте клиента, такой юмор не оценил. Это уже вопрос к аналитикам, которые не понимают то ли чего им надо, то ли как функционирует ПО.

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

scf> Если цена в неподтвержденном заказе должна всегда браться из справочника — так и берите ее всегда из справочника, а не храните в заказе. Проблема решена)
Этот вариант решения уже пройден...
Ещё раз повторю — в реальности всё озвученное нужно умножать на десять и смотреть на вопрос шире. Представьте, что сама возможность создания заказа зависит от состояния других сущностей, которые могут параллельно измениться.
Пример совсем из пальца — новый заказ не может быть создан, если у клиента уже есть два неподтверждённых заказа. Но ведь второй заказ может создать параллельно несколько пользователей, в итоге заказов станет больше двух, что является нарушением требований. И тут уже решение "не дублировать данные" никак не лезет.