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

M>>Давай разберем что. В ДДД принято идти от предметной области, а в предметной области нет никаких ER, а есть единица товара, у которой есть SKU, физическая локация (на главном склад, у перевозчика, у покупателя и т.п.) и обязательства (вернуть постащику, сжечь, поставить покупателю и т.п.) И когда ты такую модель строишь у тебя логичным образом возникает поединичный учет и резервирование товара логично превращается в метод sku_item.createObligation(Supplybbligation(Order))

M>>ER модель при этом будет выглядеть так

M>>СКУ, Единица товара, Склад, обязательство, заказ

M>>Связи:
M>>СКУ — единица товара (один-ко-многим)
M>>обязательство — единица товара (один-ко-многим)
M>>заказ — обязательство (один-ко-многим)
M>>СКУ — склад (многие-к-одному)

S>Непонятно. Какие атрибуты будут у этих сущностей?

Релевантных для задачи никаких.

S>Как устроен метод sku_item.createObligation(Supplybbligation(Order))?

Как реализуешь, так и будет устроен. Может он записи в БД создает, может API вызывает, может в файл складывает.

S>Почему метод вы написали так, а не SupplyObligation.create(sku_item, Order), и не Order.createSupplyObligation(sku_item)?

Потому что логика предметной области требует писать именно так. Обязательство это свойство единицы товара, а не самостоятельная сущность и тем более не свойство заказа. Вся идея ДДД состоит в том, что архитектура должна проистекать из домена, а не из представления архитектора о прекрасном.

S>Как мне гарантировать атомарность резервирования товаров в заказе — либо весь заказ, либо ничего?

Как тебе угодно: транзакциями, блокировами, многофазными коммитами, вручную, автоматически или через аспекты. Физическая реализация ортогональна дизайну.

Что важно, это задуматься действительно ли атомарность нужна по предметной области или это очередная выдуманная хотелка потому что все так делают? В предметной области такого требования может вообще не существовать. Допустим, ты покупаешь пакетный тур и туроператор бронирует для тебя перелет, отель и дайвинг курс. В реальности, на любом этапе ЖЦ заказа может произойти факап: рейс отменят, отель сгорит, дайв-центр потеряет аккредитацию PADI и в заказ придется вносить изменения. В том числе и порождающие финансовые транзакции в произвольном направлении.

S>По-прежнему ничего не понятно. Кто тут на кого проецируется? Я в функциональном программировании термина "проекция" не встречал. Если он общепринятый — киньте ссылку на первоисточник, если ваш — распишите подробнее.

Представь, что у тебя есть вьюха из нескольких таблиц. В классических СУБД она доступна только для чтения. А теперь представь, что ты можешь делать в нее INSERT или UPDATE и эта команда автоматически приведет к изменению исходных таблиц. Дальше представь, что это вьюха маппится на какую-то entity в коде и эта entity ведет себя неотличима от всех остальных маппингов. Вот это и есть проекция. Детали реализации могут быть совершенно любыми, от вьюх и хранимых процедур на уровне БД, до полной иммутабельности на эффектах и соответствующих монадах.