А переход игроков в другие команды тоже моделируется у вас?

Это был просто демо пример. Хотелось бы с ним только разобраться, пока без "новорочек".
Получается у нас агрегаты:
Чемпионат (содержит id всех команд)
Команды (содержит объекты игроков).
Это я уяснил. Теперь вопрос в другом.
Правильно ли я понимаю, что в сценарии добавить команду в чемпионат, у нас получается так:
1) Создаем команду с игроками.
2) Добавляем команду в чемпионат.

В таком случае у нас получается на некоторый момент ситуация, что команда без чемпионата.

А какие проблемы в команде без чемпионата?

С точки зрения реального мира это вполне нормальная ситуация.

Ну как вариант - это требование.
В GUI у нас есть форма с выбором игроков, ввода названия команды и выбора чемпионата.
В конечном итоге у нас должна создаться команда и добавиться в чемпионат.

Опять привязка к gui 😱

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

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

По смыслу, команда не является составной частью чемпионата, как и чемпионат не является частью команды. Это равноправные сущности со связью many-to-many. И вкладывать их друг в друга не надо.

Плохому танцору ноги мешают

> Команды (содержит объекты игроков)

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

отделять нужно не данные от логики, а логику от логики

смысл именно в этом, и объекты предоставляют "границу" одной логики от другой логики. Проблема обычно в том что "сущности" в общепринятом понимании это просто проекции табличек вашей реляционной БД, просто потому что так делают 90% разработчиков. Не потому что "так ооп задумывалось" (читаем про Object/Relational Impedance Mismatch) а потому что кастыли.

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

условно говоря

def foo()
{
    bar # points to internal state
}

можно раскрутить в

def foo(this)
{
    this.bar
}

Это уже разница в том как мы в коде выражаем отношения логики и данных. В Джаве это делается типами за счет классов и модификаторов доступов всяких, в каком-нибудь хаскеле типами. Смысл тот же и это вторично.

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

проблемы с сущностями (и почему например гейм дев разработчики часто агрятся на все эти вещи - мол локальность данных нарушается) - это logical cohesion. Мол "кладу в сущность данные которые относятся к сущности". И сущности это какие-нибудь Product, User, Order и прочие гигантские штуки. В такой ситуации действительно будут нарушения SRP и т.д. но не потому что логика с данными, а потому что сильно разная логика которой нужны разные данныех почему-то лежат вместе. Просто потому что "это все относится к чему-то".

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

Прекрасное объяснение 👍🏻🙌

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

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

Игрок контракт уже подписал с командой, но в команду на какуюто "секунду" еще не зачислен  В реале тоже так бывает. Бумаги подписал, но в приказе  еще не оформлен. ))

Добрый день.
Для чего делают реализуют фабрики для SQL CONNECTION'ов? "SqlConnectionFactory"
Поясните