Здравствуйте, Miroff, Вы писали:
M>Дизайн строится не от данных, а от от операций.
Это интересно. Давайте построим дизайн от операций.
M>Если у тебя не получается логично присунуть метод, значит ты что-то сделал не так.
M>Давай разберем что. В ДДД принято идти от предметной области, а в предметной области нет никаких ER, а есть единица товара, у которой есть SKU, физическая локация (на главном склад, у перевозчика, у покупателя и т.п.) и обязательства (вернуть постащику, сжечь, поставить покупателю и т.п.) И когда ты такую модель строишь у тебя логичным образом возникает поединичный учет и резервирование товара логично превращается в метод sku_item.createObligation(Supplybbligation(Order))
M>ER модель при этом будет выглядеть так
M>СКУ, Единица товара, Склад, обязательство, заказ
M>Связи:
M>СКУ — единица товара (один-ко-многим)
M>обязательство — единица товара (один-ко-многим)
M>заказ — обязательство (один-ко-многим)
M>СКУ — склад (многие-к-одному)
Непонятно. Какие атрибуты будут у этих сущностей? Как устроен метод sku_item.createObligation(Supplybbligation(Order))?
Почему метод вы написали так, а не SupplyObligation.create(sku_item, Order), и не Order.createSupplyObligation(sku_item)?
Как мне гарантировать атомарность резервирования товаров в заказе — либо весь заказ, либо ничего?
M>При этом логичным образом решаются и другие задачи, вроде "посчитать себестоимость хранения товара на складе" или "посчитать ущерб от уничтоженного товара находившегося на сгоревшем складе"
Давайте пока с простым разберемся. А потом попробуем придумать, к какому из классов приделать упомянутые вами методы.
S>>Что такое "проекции друг на друга"? Расскажите подробнее.
M>Это из функционального программирование пришло. В данном случае это обратимое преобразование F(Товар, Склад, Заказ) -> (Товар, Остаток, Резерв)
По-прежнему ничего не понятно. Кто тут на кого проецируется? Я в функциональном программировании термина "проекция" не встречал. Если он общепринятый — киньте ссылку на первоисточник, если ваш — распишите подробнее.
M>Ты можешь рассматривать проекции как DB view только не с точки зрения БД, а с точки зрения классов.
Непонятно. В DB View не ограничены проекциями (в терминах реляционной алгебры).
