Как подключить Сервис, который зависит не только от собственного Репозитория?

Question

Я работаю над стандартным Spring Boot (с Spring Web и Spring Data). Перестаньте веб-сервис и попал в эту ситуацию.

Если, например, у меня есть две сущности:

• Пользователь
• Команда

И у них есть много-многократное освобождение. Как бы выглядели их службы?

Вариант 1:

• UserService зависит от UserRepository
• TeamService зависит от TeamRepository и UserRepository

Вариант 2:

• UserService зависит от UserRepository
• TeamService зависит от TeamRepository и UserService

Я был продумывая Вариант 2, потому что каждый репозиторий связан через соответствующую службу, но из-за этого возникает следующая проблема:

Если я хочу, чтобы службы представляли только DTO, и мне нужна сущность User внутри моего TeamService для многих пользователей. многие работают с использованием Hibernate (мне нужна ссылка, а не только идентификатор). Я должен либо сделать обходные пути, либо выставить сущность из UserService.

Что может быть более ясным решением, или я что-то путаю в своих логиках c?

Редактировать:

Некоторый контекст:

Если мне нужен такой метод, как addUserToTeam (Integer userId, Integer teamId) внутри TeamService, мне потребуется получить сущность пользователя по идентификатору, чтобы добавить ее в список команды пользователи.

Answer 1

It depends. Зависит от ваших бизнес-прецедентов .. правила ...

Между Team и User есть ли какой-то владелец?

Требуется ли вашему бизнесу создать команду перед пу sh пользователей внутри? или пусть пользователи были созданы независимым способом?

Может быть, когда вам нужно создать пользователя, вы должны назначить ему команду ... может быть, нет ..

Представьте, что вам нужно создать Team, прежде чем добавить Users в себя, вы можете Team теперь рассматривается как агрегатная концепция (см. Агрегат проектирования, управляемый доменом).

DDD Агрегат - это кластер объектов домена, которые можно рассматривать как единое целое.

И так далее с этими объектами:

• Объекты / ValueObjects: Team, User
• Репозиторий: TeamRepository
• Сервис: TeamService

Так что «в этом случае» не нужно USerService or UserRepo. Каждый раз, когда вы хотите добавить / удалить / обновить пользователя, вы будете использовать Team объект / агрегат. И поэтому регистрация нового User будет осуществляться через

team.addUser(user);
teamRepository.update(team team)

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

Относительно сервиса, поскольку команда и пользователи связаны между собой понятиями, имея 2 сервиса может быть излишним.

Один сервис для поддержания жизненного цикла и согласованности между Team и Users звучит более подходящим.

Итак:

• Субъект / VO: Команда, Пользователь
• Репо: TeamRepository, UserRepository
• Служба: XXXService (XXX заменено существительным по вашему выбору)

Я просто говорю, что one service = one aggregate не является правилом ... Службы - это фасад, и фасад может обернуть модель домена, состоящую из нескольких агрегатов. Keep cohesion high - это правило.

Answer 2

Репозитории привязаны к структурам базы данных.

Услуги связаны с необходимой вам бизнес-логикой c.

Например, UserService может включать методы для получения Команд или Пользователей, если вы относитесь к одной и той же бизнес логике c.