Там сложно, это тип агрегация vs композиция и как это все перепутано. Мол что цикл жизни составных частей агрегата полностью входит в его корень.

Ток проблема что у человека задача "как загрузить данные из базы и собрать эти объекты". Как бы "юзай объекты которые ты не знаешь как собрать" так себе совет, нет?

Просто у меня агрегаты головного мозга, все дела) Я скорее отвечал не по поводу проблемы автора, а на заявление "какие агрегаты, какой cqrs, если нет коллаборативности")

ребят, в тему агрегатов

есть пеймент сервис, где есть набор сущностей

payment_intent,
payment
balance_transaction
wallet
reservation

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

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

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



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


собственно, что пришло в голову:
интент является агрегатом и содержит логику, к-ая отвечает только за него. т.е. это различные правила переходов из состояния в состояние + публикация различных событий. когда переходим в состояние completed, то через eventual consistency создаем пеймент

пеймент тоже является агрегатом, и там находится вся логика по управлению резервациями и трансферами, если этот пеймент адресован продавцу на платформе



есть у кого-то какие-то мысли по этому поводу ? Может будет более удачное решение ?

бизнес процессы при этом делятся по-факту на 2 группы
1) проведение пеймента через интент и создание самого пеймента
2) управление трансферами в рамках резервации

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

Не знаю что еще сказать. Например если "платеж" это не совсем платеж а "инвойс другому человеку по которому он уже платеж делает" то возможно есть инвойс. Без анализа процесса ничего толком сказать нельзя

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

на "фронте" каком ? В реакте, например, можешь даже не пытаться, получится полный треш

списки/кэширование запросов делать ли на уровне репозиториев либо есть красивые модели/подходы внутри бизнеса

реакт/вью

т.е. пока лушчий подход бить по фичам и слабо связывать компоненты?

окей, буду дальше брейнштормить тогда )

DDD не про код.

ну ладно занудой не будь, подскажи))

почему? если так то трэш будет вне зависимости от фреймворка. Ибо они все примерно одинаковые

идейки может или рефы, как попробывать в эту сторону

начни с вопроса "что бы что", как тебе ddd должен помочь на фронте. Размер "фронта"...

вооот, например, у меня админка, обслуживает екомерс сектор

потому что 90% приложений про "сходить на бэк - отобразить - отправить на бэк". и чаще всего это обслуживается даже без какого-либо стм

а, ну тем более у него админка