[투표] Service Layer의 반환 타입 및 Mapper 위치에 대한 아키텍처 논의

[mainlib990]

안녕하세요, 팀원 여러분. 저희 프로젝트의 아키텍처 일관성을 위해 Service Layer의 역할과 책임에 대한 기준을 정하고자 합니다.

주요 논점은 "Service Layer가 Controller에 값을 반환할 때 DTO를 사용해야 하는가, 아니면 Domain 객체를 그대로 사용해야 하는가" 입니다. 이는 객체 간 변환을 담당하는 Mapper의 위치와도 직결되는 문제입니다.

아래 두 가지 안을 읽어보시고, 우리 프로젝트에 더 적합하다고 생각하는 방식에 투표해 주세요.

---

📝 안건 1: Service Layer는 Domain 객체를 반환한다.

• 흐름: Controller ↔ Service (Domain) ↔ Repository (Domain)
• 설명: Service는 비즈니스 로직 처리에 집중하고 순수한 Domain 객체를 반환합니다. Controller가 Service로부터 Domain 객체를 받아 DTO로 변환한 후 클라이언트에 전달합니다.
• Mapper 위치: Controller 계층

장점

• Service Layer가 Presentation 계층(DTO)에 대한 의존 없이 순수하게 유지됩니다.
• 계층별 책임(Service: 비즈니스 로직, Controller: 데이터 변환 및 전달)이 명확하게 분리됩니다.

단점

• Domain 객체가 Presentation 계층까지 노출됩니다.
• Controller에서 DTO 변환 로직을 처리해야 하는 부담이 생깁니다.
• JPA 지연 로딩(Lazy Loading) 시 Service 트랜잭션 범위를 벗어난 Controller에서 예외가 발생할 수 있습니다.

---

📝 안건 2: Service Layer는 DTO를 반환한다.

• 흐름: Controller ↔ Service (DTO) ↔ Repository (Domain)
• 설명: Service가 Repository로부터 Domain 객체를 받아 비즈니스 로직을 처리한 후, 결과를 DTO로 변환하여 Controller에 반환합니다.
• Mapper 위치: Service 계층

장점

• Presentation 계층(Controller)이 Domain 모델로부터 완벽히 분리되어 API 데이터 스펙(DTO)에만 의존합니다.
• Domain 객체가 Service 계층 내에서만 사용되므로 캡슐화가 강화됩니다.
• Service의 트랜잭션 내에서 매핑이 이루어지므로 지연 로딩(Lazy Loading) 문제로부터 자유롭습니다.

단점

• Service Layer가 DTO에 의존하게 되어 Presentation 계층의 관심사가 섞일 수 있다는 비판이 있습니다.
• 하나의 Domain 객체에 대해 여러 DTO가 필요할 경우 Service가 비대해질 수 있습니다.

[kimdotcom2]

저는 이번 프로젝트는 DTO를 반환하는 게 낫다고 생각이 바뀌었네요.

일단 제 스타일은 repository를 주입 받아 공통적인 crud 로직을 처리하는 CrudService(도메인 클래스 반환)를 만들고, 그 위에 순수 비즈니스 로직만을 다루는 Service(DTO 반환)이 CrudService를 주입 받아 애플리케이션을 만드는 방식입니다.

근데 우리 프로젝트는 service 계층을 굳이 이중화 할 규모가 아니고, service에서 DB와 연관된 로직과 그렇지 않은 비즈니스 로직을 같이 처리하는 만큼, DTO를 쓰는 게 더 유연하고 controller 계층의 책임도 명확히 할 수 있다고 생각합니다.