Layered Architecture 도입을 통한 Fat Controller 문제 해결 및 관심사 분리

Thinking In Layers

Steve McDougall2026년 5월 19일8분intermediate

AI 요약

Context

명확한 책임 분리 기준의 부재로 인해 비즈니스 로직과 데이터 접근 로직이 Controller에 집중되는 Fat Controller 현상 발생. 이로 인해 코드의 재사용성이 저하되고 HTTP 요청 객체에 대한 강한 결합으로 인해 단위 테스트의 난이도가 상승하는 구조적 한계 노출.

Technical Solution

HTTP Layer: Request 수신, Validation 수행, Business Layer로의 데이터 전달 및 Response 반환에만 집중하는 구조 설계
Business Layer: HTTP 프로토콜과 무관하게 Action, Service, Domain Object를 통해 순수 비즈니스 규칙을 처리하는 계층 구축
Data Layer: Model, Repository를 통해 데이터 영속성 및 CRUD 작업만 수행하며 비즈니스 로직을 배제한 상태 유지
책임 기반 핸드오프: 각 계층이 정의된 단일 역할만 수행하고 범위를 벗어나는 작업은 하위 계층으로 위임하는 제어 흐름 적용
실용적 추상화: 단순 CRUD와 같이 복잡도가 낮은 로직은 과잉 엔지니어링 방지를 위해 Controller 내 유지하는 판단 기준 수립

실천 포인트

1. Controller 내에서 DB 쿼리나 외부 API 호출, 파일 저장 로직이 직접 수행되고 있는지 확인

2. Model 내에 비즈니스 규칙이나 상태 변경 로직(예: submitAndNotifyClient)이 포함되어 있는지 검토

3. 특정 비즈니스 로직이 HTTP 요청 외의 경로(예: CLI, Queue Job)에서도 재사용 가능한지 분석하여 Action 클래스 추출 여부 결정

4. 각 레이어가 상위 레이어의 구현 상세(예: HTTP Request 객체)를 알고 있는지 확인하여 의존성 제거

태그

#Business Logic #Separation of Concerns #Fat Controller #Domain-Driven Design #Layered Architecture

원문 읽기