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

S>Что здесь сделано некорректно, и как мы поймём, что ошибка есть?

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

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

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

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

При этом логичным образом решаются и другие задачи, вроде "посчитать себестоимость хранения товара на складе" или "посчитать ущерб от уничтоженного товара находившегося на сгоревшем складе"

S>Что такое "проекции друг на друга"? Расскажите подробнее.

Это из функционального программирование пришло. В данном случае это обратимое преобразование F(Товар, Склад, Заказ) -> (Товар, Остаток, Резерв)
Ты можешь рассматривать проекции как DB view только не с точки зрения БД, а с точки зрения классов.