Service 간 의존

• 보통은 Service 간 의존하면 순환 참조 문제가 발생하고 도메인 간 경계가 흐려져, 지양하는 것으로 알려져있지만,
  두 개념의 상하 관계가 명확하다면, 상위 개념에서 하위 개념의 Service를 의존성 주입받는 것은 괜찮음!
• 또, Service를 주입받아서 사용을 하게 된다면, 자연스레 Service단의 검증, 생성, 저장 등의 로직을 사용할 수 있어서 장점이 있다.
• 하위 개념이고, 상위 개념의 객체를 생성할 때의 부수물로 하위 개념의 객체를 생성해야한다면 그 때 Service 의존!

예시

• ChannelService에서 PrivateChannel을 만들 때 ReadStatus 객체를 생성하는게 필수일 때,
• ChannelService에서 ReadStatus 객체를 직접 생성하고 검증하는 것은 SRP 위배 + 중복 코드 발생
  => ChannelService와 ReadStatus는 명백한 상하 관계이므로, ChannelService에서 ReadStatus를 의존성 주입받고, ReadStatus 객체 생성 및 검증을 위임!
  

해도 되는 경우

• 포함된 도메인을 생성하거나 검증할 필요가 있는 경우
• 예를 들어, MessageService에서 메시지를 생성할 때,
  메시지에 포함되는 BinaryContent (이미지, 파일 등) 객체도 같이 생성하는 경우

public Message createMessage(CreateMessageRequest req) {
    BinaryContent binary = binaryContentService.saveBinary(req.getFile());
    ...
    return new Message(..., binary);
}

• 이처럼 BinaryContent는 메시지 안에 포함된 하위 개념이고,
• BinaryContentService를 통해 검증이나 저장 로직을 위임하는 건 자연스럽고 설계적으로도 안전하다!

해서는 안 되는 경우

• 독립적인 도메인끼리 직접 Service를 의존할 경우
• 예를 들어, UserService에서 메시지 내용을 직접 참조하거나, ChannelService에서 유저 상태를 관리하려는 경우

UserService 

public void someLogic() {
    Message msg = messageService.findLatestMessage(userId);
}

• 이런 경우는 User와 Message가 각각 독립적인 도메인이기 때문에
• Service 간 직접 의존을 만들면 결합도가 높아지고 순환 참조 위험도 커진다.
• User, Channel, Message처럼 독립적인 도메인끼리는 서로 간 Service 의존 없이,
  필요한 정보만 ID나 Repository를 통해 조회하는 방식이 이상적이다.

=> 포함 관계라면 Service를 의존해도 된다. 하지만 서로 독립적인 도메인이라면, Service가 아닌 Repository나 ID 기준으로 참조하자.