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

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

То есть задача манипулирования заказами начинает расползаться на большее кол-во сервисов, не только на ЗаказМнеджер?

S>Как раз в rich domain model непонятно, где располагать такой метод — в заказе, в складе, или еще где.

rich model не отрицает наличие сервисов.

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

с поведением?

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

ой, не факт. на договоренности надейся, а сам не плошай.

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

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