Нет, корзина не будет валидировать. Сущность заказа Order будет

Конечно это только мое видение

А что тогда будет из себя представлять "Order". Для меня это когда корзину хотят оформить в заказ. Тогда и получается Order

Ну условно говоря это будет агрегированный продукт с дополнениями. Название конечно можно более подходящее.

Благодарю. Единственное смущает, что сущность Order будет много знать о продукте и дополнениях. Возможно я неправ

Так и должна знать. Это обёртка. А её ты уже передашь в корзину

почему нельзя сделать ComplexOrderComposer или что-то в этом роде?
прежде чем попасть в корзину айтемы(любые айтемы) проходят через композер, который "дополняет" заказ доводя его до валидного состояния, укладывает туда "обязательные" айтемы, и/или "подарки". в корзину в итоге попадают валидные сборки

помоему проблема вот тут

"Сущность Product имеет несколько доступных ему Addition'ов. Они могут быть обязательными и необязательными."

Возможно Product не стоит знать про то что у него есть Addition? сегодня у бургера обязательное дополнение это лук, завтра салфетка. бургер при этом остается не изменным, а меняют правила компоновки независемыз сущностей в комплексную сущность

благодарю за ответ. сейчас это и делаю, только через билдер

а как еще можно сделать? Ну т.е. нет правила, что дополнение может добавиться к любому продукту. У продукта есть доступные дополнения. К бургеру нельзя добавить палочки, как и к сушам нельзя добавить помидор

Почему? Почему нельзя так сделать?

потому что доступные модификаторы рознятся от продукта к продукту

Вы делаете слишком раннию валидацию
При добавлении в корзину вам вообще должно быть пофиг на ограничения они важны только при покупке непосредственой
далее вы просто делаете Аггрегат\модель на вроде OrderAdditional который и пытетесь исполнить и который наполняете в процессе работы необходимыми данными

Лучше чтобы айтемы знали о продукте а не продукт об айтеме
продукт более стабильный он не должен зависеть от менее стабильных айтемов

++, это имел ввиду)

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

Ну сущностью тут не пахнет а так я понял. У вас будет калькулятор обычный он будет один без идентификаторов и прочего

да имелся ввиду класс без экземпляров

я сразу могу порекомендовать избегать "больших" сущностей. Мол вместо Product делать набор маленьких сущностей которые между собой объеденяются айдишкой. Меньше лучше. Выявлять правила и инварианты. И уже вокруг них строить агрегаты.

Вообще то о чем ты пишешь никакого отношения к DDD не имеет.

ты просто по сути модель данных без привязки к юзкейсам и инвариантам обсуждаешь.