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

S>>Вот мне интересно, какие объекты будут появляться в DDD, и как они будут работать. Будет ли rich object model, или анемика?
PJ>Вот все перечисленные объекты и должны быть в модели. Буквально.
Это как раз понятно. Непонятно, какие будут методы у этих объектов.
PJ>При этом модель должна быть непротиворечивой и все типы всегда валидны, следуя принципу make invalid state unrepresentable. Вот это и будет твоя модель — внутренний круг онион-архитектуры.
Утопический принцип. Валидность состояния — это миф. Она имеет место только в рамках конкретного сценария. Вот, скажем, заказ в состоянии "новый" вполне может содержать в себе позиции, которых нет на складе. Ну, нету и нету.
А вот, например, зарезервировать заказ можно только в том случае, если всё заказанное готово к резерву.
Опять же — в состоянии "новый" заказ может не иметь данных о покупателе, но для того, чтобы сделать его "оплаченным" эти данные необходимы.
Чтобы перевести его в статус "в доставке" нам нужно иметь в заказе не просто адрес доставки, а адрес, распознанный нашим шиппинг-партнёром.
Как вы собираетесь описывать все эти ограничения при помощи системы типов?
Либо у нас будет 2^N типов "заказ", и трансформации будут менять тип заказа. Либо понятие "invalid" у нас сузится до несуществующего, и тип "заказ" будет разрешать вообще всё, убрав все статические ограничения. Кроме тривиальщины — ну там, типа "заказ не может содержать 0 позиций". И то есть риск, что придётся убрать и это ограничение под давлением обстоятельств.

PJ>Потом добавляешь слой бизнес логики, который позволят трансформировать модель из одного состояния в другое. Типа как ордер превращается в валидный ордер, а валидный в оплаченный итп. Зачем оно так делает в данном случае несущественно, главное чтобы инвариант сохранялся.
То есть всё же имеем 2^N типов?
PJ>В третьем слое — application logic, собственное сами сценарии, как и когда что работает. По-хорошему, это просто композиция функций из предыдущего слоя. И последний слой это инфраструктура или порты, который связывает все это с внешним миром. Там живут все DbConnection и прочие файлы. Зависимости всегда направлены внутрь. Собственно и все. Легко тестируется, легко поддерживать, легко понять что происходит, сломать трудно. Отлично масштабируется. Если калькулятор, то это все что надо, если кровавый энтерпрайз, то это один из BC. Как-то так.
Отлично. Давайте применим эти абстрактные рассуждения к рассматриваемой задаче. Какие классы (или функции) у нас будут в "модели", какие — в "бизнес логике", какие — в "application logic".
Дьявол в деталях. Направление зависимостей, loose coupling и tight cohesion упоминают поклонники всех типов дизайна.