Fat Controller 해결을 위한 3-Layered Architecture 기반의 관심사 분리

Layering — Separation of Concerns

Nghề không nhiều chẳng sắc2026년 6월 29일6분intermediate

AI 요약

Context

비즈니스 로직이 HTTP Handler에 밀집된 Fat Controller 구조로 인해 발생하는 강한 결합도 문제를 분석. 이로 인해 Cron Job이나 CLI 등 비-HTTP 환경에서 로직 재사용이 불가능하며, Request/Response 객체에 의존적인 테스트 구조로 인한 유지보수 효율 저하가 발생함.

Technical Solution

Controller $\rightarrow$ Service $\rightarrow$ Repository로 이어지는 단방향 의존성 계층 설계
Controller의 역할을 HTTP 요청 해석 및 서비스 호출로 제한하여 Thin Controller 유지
순수 비즈니스 로직을 Service 계층으로 격리하여 외부 인터페이스(HTTP, Message Queue, CLI)와 무관한 도메인 로직 구현
데이터 액세스 로직을 Repository 계층으로 캡슐화하여 DB 스키마 변경 시 영향 범위를 최소화
CRUD 수준의 단순 기능에는 Service 계층을 생략하는 Pragmatic Layering 적용으로 Over-engineering 방지

실천 포인트

- Handler 내에 DB 쿼리나 비즈니스 결정 로직(if문 등)이 포함되어 있는지 확인 - 동일한 비즈니스 로직이 HTTP 핸들러와 백그라운드 잡에 중복 구현되어 있는지 검토 - 서비스 계층 테스트 시 HTTP Request/Response Mocking 없이 순수 함수 형태로 테스트 가능한지 검증 - 단순 필드 추가 시 수정해야 할 파일이 과도하게 많은지 확인하여 Over-layering 여부 판단

태그

#dependency-management #Separation of Concerns #Domain Logic #Fat Controller #Layered Architecture

원문 읽기