Link 도메인 구조 리팩토링

[ckdals4600]

이슈 배경

• 현재 LinkService가 DTO를 직접 반환하고 있어, 다른 Facade나 서비스에서 해당 메서드를 재사용하기 어렵고 계층 간 역할이 모호함.
• 또한, Controller의 응답 타입이 ResponseEntity로 감싸져 있어 프로젝트 코드 컨벤션(BaseResponse 직접 반환)과 일치하지 않음.
• 이를 해결하기 위해 계층 간 반환 타입과 API 응답 구조를 재정비하고자 함.

이슈 내용

1. Controller & API 응답 구조 변경 (LinkController, LinkApi)

• ResponseEntity 제거:
  • 기존: ResponseEntity<BaseResponse<T>>
  • 변경: BaseResponse<T>
  • 목적: 불필요한 래퍼 클래스를 제거하고 프로젝트 전반의 응답 포맷 통일.
• 검증 책임 이동:
  • Controller에 남아있는 비즈니스 검증 로직이 있다면 Facade로 이동시켜 Controller는 오직 HTTP 요청/응답 매핑 역할에만 집중하도록 경량화.

2. Service 계층 반환 타입 변경 (LinkService)

• Entity 반환 원칙 적용:
  • 기존: LinkService가 LinkRes(DTO)를 반환.
  • 변경: LinkService는 **Link(Entity)**를 반환.
  • 예외: 엔티티 간의 결합이나 통계 데이터 등 순수 엔티티로 표현하기 어려운 경우에만 DTO 사용.
• 이점: LinkService의 메서드를 다른 도메인(예: Chat, Report)에서 호출할 때, DTO가 아닌 엔티티를 받음으로써 비즈니스 로직 확장이 용이해짐.

3. Facade 계층 역할 강화 (LinkFacade)

• DTO 변환 담당:
  • Service로부터 Link 엔티티를 받아, Facade에서 LinkRes DTO로 변환하여 Controller에 반환.
• 트랜잭션 관리:
  • 엔티티를 반환받아 DTO로 변환하는 시점까지 Transactional 범위를 유지하여 Lazy Loading 이슈 방지.

변경 전/후 흐름 비교

[Before]
Controller (ResponseEntity) -> Facade (Pass-through) -> Service (Logic + DTO Conversion)

[After]
Controller (BaseResponse) -> Facade (Flow Control + DTO Conversion) -> Service (Logic + Entity Return)

참고 자료

No response