Refactor/161 : Facade 도입 & 클래스 의존관계 개선

[swa07016]

🚀 개요

#161

기존의 전형적인 3계층 구조는 아래와 같은 문제점을 가지고 있었습니다.

1. Controller (API)
   • 여러 엔티티로 구성해야하는 응답 DTO가 있을 경우, 여러 서비스를 의존해야합니다.
   • 서비스로 부터 Entity를 받기때문에 테이블 세부 구현을 알게 됩니다.
   • 받은 엔티티를 응답 DTO로 변환하는 책임을 지고 있습니다.
2. Service (Business)
   • 복잡한 비즈니스 로직을 구성하기 위해 여러 리포지토리를 의존해야합니다.
   • 여러 엔티티에 대한 처리로직으로 인해 Service계층의 재사용성이 떨어집니다.
   • 요청 DTO를 엔티티로 변환하는 책임을 지고 있습니다.

🔍 변경사항

Controller와 Service 사이에 Facade 계층을 추가했습니다. (4계층 구조입니다.)

1. Controller)

   • 클라이언트로 부터 요청을 받고 응답하는 것에만 집중합니다.
   • 클라이언트 요청 데이터의 유효성을 검사나 응답 캐싱 등 클라이언트와의 상호작용 가장 앞단의 책임만 가집니다.

2. Facade)

   • 재사용가능한 여러 서비스를 조합하여 비즈니스 로직을 구성합니다.
   • 트랜잭션을 관리합니다.
   • Converter를 의존하여 DTO ↔ Entity간 변환을 수행해줍니다.

3. Service)

   • 연관된 엔티티의 CRUD만을 담당합니다.
   • XQueryService) X엔티티의 Read를 담당합니다.
   • XCommandSerivce) X엔티티의 Create, Update, Delete를 담당합니다.

📝 논의사항

API 버전관리에 따라 Facade에 중복코드가 두 개의 메소드 정도에 있는데, 해결할 방안을 고민해보겠습니다. 이 부분은 추후 다른 이슈로 다루겠습니다.