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

T>>Откуда CustomerManager и как он может помешать изменить Customer-а напрямую?
S>Как откуда? Это и есть класс, в котором сосредоточены методы управления кастомерами.

Все равно вопросы остаются. Не совсем понятно где располагать методы, манипулирующие несколькими типами сущностей.
Например, если чуть изменить тот пример с резервированием:
пусть в случае отсутствия на складе нужного количества товара, товар резервируется частично и информация о зарезервированном кол-ве сохраняется в заказе. То есть, если мы хотели заказать 50 стульев, а на складе оказалось только 20, то 20 и зарезервируется, а после того, как на склад довезут товар, можно будет до-зарезервировать оставшиеся 30 стульев.
В такой формулировке операция резервирования меняет как остатки на складе, так и строки заказа.
В DDD для такого сценария был бы заведен ReservationService, в котором и был бы расположен весь код и по списанию остатков, и по обновлению заказа.
А куда вы его поместите?

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

Ну, от злодея-админа ничего не спасет, так что лучше такой вариант не рассматривать.

S>А вот запретить из прикладного кода вызовы апдейт-стейтментов можно в том числе и при помощи FxCop.
S>Это если не хватает культуры программирования.
S>Нужно просто отделить случайные ошибки от преднамеренных действий.

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

S>>>А если подумать головой, то окажется, что зип-код нужен только в тот момент, когда выполняется отгрузка товара. Если кастомер хочет заказать и заплатить, то нет никакой причины требовать от него валидность ненужного сейчас зип-кода.
T>>Ну это скорее аргумент в пользу изменени логики валидации — она должна запускаться только при определенном статусе заказа.
S>Это приведет к тому, что в приложении вообще не будет повторно используемого кода. Потому что в логику валидации зашито слишком много подробностей про окружение. А всего-то надо было применить регекс в нужный момент.

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