Потому что к заказу относится

Так что относится к заказу, при условии, что туда откуда-то кто-то передаст аж сам сущность заказ? Менеджер какой-то ещё? Который контроллер вызовет? :)

А бывает payment без заказа?

Да кто его знает )

Всякое бывает

Я просто на слово payment тригерюсь, поэтому и спрашиваю -_-

Много вариантов, как это сделать )

Вариантов много, рецепт один ☺️

В этом слое всё будет на Service заканчиваться? Зочем?

это рофел )

А Ну тогда ок. А то у меня тут в проекте тоже так все рофлят. Куда не плюнь - везде сервис.

Привет :) Раз зашла речьо заказах :)
А как лучше делать историю при высокой декомпозиции?
При жирной сущности, история пишется прямо в ней в единую таблицу типа OrderHistory.
Разбили допустим на 3 мини агрегата: OrderBalance (заказ можно оплачивать кусками/траншами, нужно где-то отслеживать оплечен/частично оплачен). OrderItems - тут коллекция товаров. OrderDelivery - инфа о доставке.    
куда писать Делать 3 таблицы историй OrderBalanceHistory и тп, а потом собирать из кучи таблиц в одну при чтении, или же выносить запись истории наружу и писать так же в одну OrderHistory например через ивенты

пичалька...

Можно заменить тогда, чтобы было очевиднее.
OrderRofl, UserRofl, DDDHelperUtilRofl..,

Это была ирония

Иначе он у тебя будет как энтити называться )

UserEntity -> User
UsersController -> Users
UserService -> User
UserRepository -> User

красота

О, ну этого хватит. Service + Entity = Love(DDD)

можно в 1 полиморфную табличку засунуть )
order | action | context (json)