숙련) 일정관리앱 트러블슈팅 (4)

스탠다드 반에서 MSA 강의를 들으며 물리적인 DB 분리에 대한 내용을 공부했다

지금은 한 DB 에 모든 Entity, Table 의 내용을 저장하지만 이후 실무에서 DB 가 분리된다면 한 service 계층에서 모든 respository 를 다 가져와서 사용할 수 없게 됨 

사용하고싶어도 아예 접촉할 수 없는 DB 가 존재하게 되므로 service 계층에서 하나의 repository 만 DI 하고 나머지 repository 는 해당 repository 에 접근할 수 있는 service 를 DI 함으로써 구현

repository 를 DI 하던걸 취소하고 service 를 가져왔다.

각 Service 에 원래 repository 에서 할 수 있는 메서드들을 선언하고 사용했다.

# Optional 처리가 된 Schedule 반환
public Schedule getScheduleById(Long scheduleId){
    return scheduleRepository.findById(scheduleId).orElseThrow(
            ()->new ServiceException(ErrorCode.SCHEDULE_NOT_FOUND)
    );
}

예시!

근데 이런 귀엽고 예쁜 오류가 발생했다

떴는데 기분 좋은 오류는 처음이다...

 

그래도 Service 를 DI 하니까 오류가 나길래 ... 이 접근이 MSA 를 구현하는게 아닌가 해서 튜터님께 여쭤봤다 

ㅋㅋ 귀엽당

Bean 을 DI 하는 과정에서 순환참조가 발생하면 오류가 발생함

결론! 목적형 Service 클래스를 분리하라 현재는 Comment Service 에서 Schedule Service 를 직접 DI 하는데 사실 Comment Service 에는 Schedule Service, repository 의 모든 메서드를 가질 필요가 없다 필요한 메서드만 따로 Service 에서 가져오면 됨 -> 읽기 전용 class 분리해주기

@Service
@RequiredArgsConstructor
public class ScheduleReadService {
    private final ScheduleRepository scheduleRepository;

    public Schedule getScheduleById(Long scheduleId){
        return scheduleRepository.findById(scheduleId).orElseThrow(
                ()->new ServiceException(ErrorCode.SCHEDULE_NOT_FOUND)
        );
    }

    public boolean chkExistScheduleById(Long scheduleId){
        return scheduleRepository.existsById(scheduleId);
    }

}

ScheduleReadService 를 만들어주면 순환참조 해결~