@fes0r спасибо большое

это не агрегаты. это пока просто сущности. Возможно там где "Something has something" у тебя должно быть "something is associated with something" и в этом случае ограничиваемся просто идентификаторрами и все живет себе независимо.

Ну то есть это всё-таки 2 процесса

агрегаты повтоорюсь появляются когда у тебя операции есть. Потому что повторюсь - агрегат = граница логической транзакции

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

Операции - это какая-то логика?

ну вот у тебя есть стэйт какой-то. Аля команды игроки и т.д. Нам все эти агрегаты и т.д. не интересны когда стэйт статичен.

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

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

Условно говоря - по умолчанию каждое свойсво системы - это свой агрегат. И только если два свойства влияют друг на друга и ну никак мы не можем допустить что бы стэйт был даже временно неконсистентным - вот тогда оно должно быть в одном агрегате.

в этом плане лучше расписывать процессы а не сущности. Мол что люди делают

event storming хорошо для этого подходит например

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

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

не должно быть "большой вложенности".

ну то есть пересматривать как ты чего разбил.

А как аффектит нижний уровень вложенности внешний?

все операции с нутром агрегата происходят через корень агрегата. Иначе у тебя не соблюдается основная идея агрегатов - что все операции над стэйтом происходят атомарно.

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

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

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

(есть метрика - lack of cohesion - она может давать подсказку ок у тебя агрегаты или не ок)

Благодарю вас за совет. Сейчас начал все переделывать и реализовывать заново.

Если можно ещё один вопрос по поводу паттерна Builder, который якобы собирает нетривиальный объект со своими правилами. Правильно ли я понимаю, что все бизнес правила  переезжают в него? Либо они все же остаются в сущности? Тогда зачем нужен билдер не совсем понимаю

Спасибо за развернутый ответ!