может быть тебе надо имень несколько агрегатов, а не один? думаю не очень разумно загружать данные, которые не будут использоваться в операции

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

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

у тебя над договорами, позициями и закрывающими доками в нутри одного агрегата в один момент времени работает только один человек? (не считая чтения)

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

вообще одним из первых звоночков что зря я так разделил на несколько агрегатов - было то что мне надо было 3 агрегата обновить в одной транзакции

а может быть такое, что представлять покупателя или продавца могут несколько человек, и например на этапе подписания продавцом, параллельно подписываются документы одного агрегата разными людьми?

уверен что тебя нужна там именно транзакционная консистентность? очень часто можно разрулить c eventual consitency

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

"часто" это значит "не всегда"? а почему так?

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

одно из действий всегда требует сверяться с другим агрегатом)
но написал "часто")

ну тут опять же, почему, как оно сверяется, как может случиться что инвариант одного будет нарушен?

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

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

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

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

Просто это ж все не просто так надо.

Ну, у нас ддд, не я выбирал) плюс тема интересная, изучаю вот на практике, агрегаты еще тестить оч удобно)

Предвижу "скорее всего у вас говно получится".. не исключено) но мы стараемся)

и как ты хедлишь ситуацию, когда приходят два запроса на подпись одновременно? надеетесь на транзакции в бд?