[REFACTOR] 프로젝트 전반적인 구조를 리팩터링한다.

[kssumin]

구조 관련하여 리팩터링 할 사항들을 작성한다.

[kssumin]

usecase 계층을 없애고 controller -> service를 바로 의존하도록 변경한다.

• usecase 자체가 변한다는 것은 service 자체도 변할 수 밖에 없다.
• 즉 service에 대한 추상화가 필요한가? 라는 의문이 들어 service의 추상화로 사용한 usecase 계층을 제거한다.

결론

• usecase 추상화 계층을 제거한다.
• 다만 도메인Service는 한 계층이 가지는 책임이 너무 크다.
• 따라서 행위에 따른 Service로 클래스명을 변경하여 사용한다.

[kssumin]

단순 조회인 경우 service -> service에 대한 의존을 제거하고 repository에 의존하도록 변경한다.

• 본래 도메인과 관련된 service에서만 repository에 의존할 수 있도록 조회와 관련한 행위를 수행하는 service 계층을 따로두었다.
• 하지만, 이 경우에 AService -> BService에 의존을 해야하고 그럼 BService의 모든 메서드에 접근이 가능한 문제가 있다.

결론

• 조회를 한 이후에 특정한 행위를 수행하는 책임을 가진 경우의 service일 경우에는 service -> service를 의존한다.
• 단순한 repository에서 객체 조회인 경우에는 service -> repository에 의존하도록 한다.

[kssumin]

Repository의 디렉터리 위치를 변경한다.

• Repository는 객체 관리 저장소이다.
• 즉, DB와 관련된 개념이 아니다.
• 하지만, 지금은 Repository가 마치 DB에 종속적인 존재로 infra 계층에 속해있다.(인메모리 : HashMap으로 객체를 관리하는 것도 Repository 이다.)

결론

따라서 Repository 계층을 business 계층으로 변경한다.