третий вариант в предложенной реализации выглядит вообще ужасно(

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

Мне сложно сказать не понимая основной задачи. Пока что в предложенном драфте лишь описание структуры. Как она должна работать - совершенно другой вопрос который как раз неясен. Для меня очевидно, что Tournament просто объеденяющее звено. Как миниму нужно разбить всё на Team, Game и Tournament. Судя по названию методов разные состояния должны быть в том числе для Game. Наверное делая finishGame() нужно делать и startGame(). Метод registerTeam() наверное вообще нужно вынести и не позволять создавать Tournament без набора команд. Если их количество и правда меняться в процессе - нуу, надеюсь это не так иначе это странный турнир. Можно не делать состояния а представить всё в виде отдельных этапов объядиняющихся в один турнир. У каждого этапа свой набор входящих сущностей для функционирования и манипулирования. Подсчёт очков - тоже в отдельную сущность - будет принимать на вход команды, их результаты, тип турнире (если будет нужен) и определять итог

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

Эрик Эванс голову не раз пеплом посыпал что в своей синей книги про сущности ажно в первой половине книги втирал - мол теперь хрен переучишь

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

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

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

🐒 Не понял связи между созданием сущности и сменой id. Типа разные состояния хранятся отдельно? Можно подробнее ...? Спасибо =)

Ну тип неудобно на разные статусы заказа разные таблицы в бд делать

В коде я делаю типа $createdOrder = $draftOrder->publish();, а в бд хочу чтоб статус в таблице сменился

А, это ясно=)

мммм не оч понимаю зачем айдишки менять...

удобно)

Ой, статус я имел ввиду

можно просто key-value для агрегатов)

тебе всеравно на запись больше ничего не надо обычно

Искать как?

Не у всех есть рид модели отдельные)

а ты ищешь на запись? На чтение можно вьюшки в базе делать)

Оно ж медленно будет искать?

как сделаешь так и будет. Есть материализованные вьюшки с индексами и всеми делами)