Controller에서의 로직 분리에 대한 논의 (feat. Facade 패턴 도입..?)

[s0o0bn]

현재 PR(#53) 올라온 것에 대해 아직 코드를 다 보진 못 했습니다.
일단 PR 포인트에 적어주신 내용과 StudyTimeController의 코드를 보고 떠오른 생각이 있어 안건을 제안합니다.

결론부터 말하면, 현재 Controller에서 최초 사용자 요청 DTO를 서비스에 넘기고 최종 응답을 반환하는 과정에서
그 사이에 있는 로직 (Service 간의 데이터 전달) 또한 비즈니스 로직에 해당한다고 생각됩니다.
따라서 해당 로직을 별도의 컴포넌트에서 담당하도록 분리하는 게 어떨까 싶습니다.

일반적으로 위와 같은 구조를 Facade 패턴을 적용했다고 많이들 하는 것 같습니다.
Service 레이어 위에 Facade 계층을 두고, Controller에서는 해당 Facade의 메서드만 실행하는 거죠.

저 같은 경우, 이전 프로젝트에서 팀원의 제안으로 Service 계층 아래에서 컴포넌트를 분리하는 아키텍처를 사용한 경험이 있습니다.
본질 자체는 크게 다르지 않다고 생각해 어느 방식을 사용하든 상관은 없지만, 왠지 지금까지 구현된 코드를 고려했을 때,
Controller 내부 로직을 대신 담당하는 계층(즉, Facade)으로 분리하는 게 더 효율적일 거 같다는 생각이 듭니다.

좀 더 풀어 설명하면, 이전에 말씀하신 바와 같이 Controller의 본질적인 목적은 "사용자의 요청을 로직 처리 담당 객체(Service)에게 넘기고,
그 객체로 부터 넘겨받은 최종 응답값을 사용자에게 반환한다"라고 생각합니다.
그 과정에서 어떤 도메인이 상호작용해서 최종 응답이 만들어지는 지는 Controller에서 알아야 할 내용은 아닌거죠.

그런데 현재 저희 구조에서는 아무래도 기능 특성상 로직이 복잡할 수밖에 없고, 다양한 도메인의 서비스가 전체 로직에 포함되는 경우가 많다고 생각합니다.
그러다보니 구현해주신 것처럼 Controller 자체에서 여러 개의 Service를 호출하게 되고, 그만큼 그 사이에서 사용하는 모든 DTO를 알아야 할 것입니다.
또한 Controller에서 특정 요청에 어떤 서비스들이 관여하고, 어떤 순서로 호출되는 지를 직접적으로 알아야 한다는 게 과연 적절한가 라는 생각에 이런 논의를 열게 되었습니다...

이것도 더 일찍 논의했으면 좋았을 텐데, 미처 생각하지 못했네요...
그런데 일단 더 복잡한 기능들이 추가되고 코드가 늘어나면 돌이킬 수 없어질 것 같아서 제안드리게 되었습니다.
글이 좀 길어졌는데 어떻게 생각하시는지 궁금합니다.

---

위 방식으로 리팩토링 및 추후 기능 구현 시 적용한다고 가정했을 때, 최근 제가 구현한 그룹 생성을 예로 들면 아래와 같은 흐름이 될 것입니다.

• 요청한 GroupTag의 유효성을 확인합니다. -> GroupTagService
• 요청값을 기반으로 Group을 저장합니다. -> GroupService
• 요청한 사용자의 Member 객체(프록시)를 조회합니다. -> MemberService
• 해당 사용자에 대한 GroupMember를 저장합니다. -> GroupMemberService

각각의 항목은 해당 도메인 Service에서 담당하고, GroupFacade에서 저 서비스를 호출하며 전체 로직을 구성하는 거죠.
그리고 GroupController는 @RequestBody에 해당하는 DTO를 Facade에 넘기고, Facade가 반환한 DTO만 클라이언트로 반환하게 됩니다.

[unikal1]

퍼사드 패턴 사용 자체는 괜찮은 것 같습니다. 다만, 진짜로 필요한가? 라는 고민이 좀 필요는 할 듯 합니다.

일단 제가 작성한 코드에서 StudyTimeController 의 역할이 비대해 졌다는 내용은 동의합니다. 이 과정에서 퍼사드 패턴의 유용성 자체도요. 다만, 시스템 전체적으로 볼 때, 퍼사드 패턴이 필요할 정도로 복잡한가 하면 아니라고 봅니다.

특히 예시로 드셨던 그룹 생성을 보면, 엔티티를 퍼사드 계층까지 가져오는건 좀 위험할 것 같습니다.
만약 퍼사드 패턴을 사용한다면, groupMemberService에서 member 조회까지 처리하는 편이 좋겠네요.

제가 생각하는 방식 중 하나는, 단순CRUD, 혹은 하나~두개 정도의 serivce에 대한 의존성을 지니고, 그 데이터 정제가 간단한 경우 conroller 에서 service를 직접 주입받아 사용하고, 만약 service 의존성이 좀 많거나, 저같이 데이터 처리 과정이 조금 복잡해지면 퍼사드를 사이에 두는 편은 어떤가요?

[s0o0bn]

📣 회의 결론

Facade 계층과 Implement(Worker) 계층의 조합

각 계층의 목적

1. Facade
   여러 개의 Service가 상호작용하며 데이터를 주고 받는 복잡한 로직을 감싸는 역할. (ex. 통계 등)

2. Implement
   덩어리로 묶일 수 있는 로직을 분리해, 재사용성을 높이고
   요구사항 변경 혹은 확장 시의 Service의 비즈니스 로직 변경 최소화.

Controller - Service

1. 단순 CRUD, 하나의 Service에서 처리 가능한 경우
   기존 방식대로 Controller에서 해당 Service 호출하는 방식

2. 여러 Service가 조합되어야 하는 경우
   별도의 Facade 전용 Controller를 두어, Facade를 호출하도록
   트랜잭션은 Service 계층에서 Implement 계층의 조합으로 관리할 것, 따라서 Facade에서는 트랜잭션 ✖️
   Entity가 Facade까지 올라오는 것 지양.

패키지명 facade, 클래스명에 Facade Postfix 명명.

Service - Repository

Service - Implement - Repository(DAO)
위에서 언급한 아키텍처 기반의 구조

Service에서는 Implement(Worker) 컴포넌트만 의존함.
Implement 컴포넌트는 동일 계층의 컴포넌트와 Repository를 의존함.

하나의 덩어리, 즉 같은 책임에 포함되는 로직을 Worker 컴포넌트의 메서드로 분리해서 사용.
이때 유사한 책임을 갖는 메서드는 하나의 컴포넌트에서 담당.

동일한 트랜잭션에서 수행되어야 하는 로직을 Service 메서드에서 관리.

패키지명은 worker로 두나, 클래스명은 담당하는 역할에 따라 Postfix 없이 명명 (ex. MemberFinder, GroupEntryCodeGenerator 등)