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

T>В DDD для такого сценария был бы заведен ReservationService, в котором и был бы расположен весь код и по списанию остатков, и по обновлению заказа.
T>А куда вы его поместите?
В этом подходе точно так же будет ReservationService. Как раз в rich domain model непонятно, где располагать такой метод — в заказе, в складе, или еще где.

А так у нас есть некий сервис, которому для работы нужны заказы (с определенным поведением), и склад.

T>В том-то и вопрос, как избежать случайных ошибок.
Очень трудно сделать случайную ишибку, если есть определенные договоренности.

T>Не совсем верно выразился. В описанном случае отсутствие zip-кода или его невалидность вообще не должно учитываться при валидации кастомера. Это действительно, скорее пред-условие для осуществления отгрузки.
Я просто веду к тому, что в реальной жизни инвариантов, которые можно безопасно захардкодить в класс ентити, практически не встречается. В развитых системах те же предусловия на операции вообще задаются путем конфигурирования workflow, без какой-либо перекомпиляции.