Spring Boot MVC 모델과 폴더 구조

MVC 모델

MVC는 Model, View, Controller 세 요소로 이루어진 구조다.
역할을 분리해서 코드가 커져도 유지보수가 가능하도록 하는 핵심 개념이다.

Model

데이터와 그 데이터가 지켜야 하는 규칙을 담는 부분이다.
예를 들어 Member라는 객체는 이름을 반드시 가져야 하고, 가격은 음수가 될 수 없다는 식의 규칙이 여기 들어간다.
스프링에서는 주로 Entity(도메인 모델) 형태로 등장하고, 외부 전송용으로는 DTO 형태로 따로 나눠지기도 한다.

View

사용자에게 보여지는 결과물이다.
과거에는 HTML 템플릿이 View 역할을 했지만, 지금은 REST API 개발이 많기 때문에 JSON 응답이 사실상 View 역할을 한다.

Controller

클라이언트의 요청을 받고, 어떤 작업을 수행할지 결정하는 입구다.
Controller는 일을 “직접” 하지 않고, 적절한 Service에게 일을 시킨다.
흐름을 조율하는 조정자 역할이다.

스프링에서의 확장된 구조

스프링은 MVC를 한 단계 더 확장해서 다음과 같은 구조로 사용한다.

Controller
↓
Service
↓
Repository

Controller에서 로직까지 다 처리하면 코드가 바로 비대해진다.
그래서 실제 작업은 Service에서 처리하고, 데이터베이스와의 대화는 Repository에서 맡는다.

Service

비즈니스 로직이 들어가는 곳이다.
Controller는 Service에게 “회원 가입 처리해줘” 같은 식으로 요청하고, Service가 실제 로직을 수행한다.

Repository

DB와 통신한다.
Service는 Repository에게 “이 정보 저장해줘” 또는 “이 데이터 가져와줘” 라고 요청한다.

Domain(Entity)

프로젝트가 다루는 개념 그 자체.
Member, Order, Product와 같은 실제 존재하는 개념이 여기에 위치한다.
프로젝트의 세계관을 구성하는 핵심 모델이다.

DTO

요청과 응답 시 사용하는 데이터 전달용 객체다.
Entity를 그대로 외부에 내보내면 내부 설계가 그대로 노출되기 때문에, 외부로 주고받는 데이터는 DTO라는 택배 상자를 통해 전달하는 방식으로 분리한다.

폴더구조

src
 └─ main
     ├─ java
     │   └─ com.eecsjlee.springbootintro
     │        ├─ controller
     │        ├─ service
     │        ├─ repository
     │        ├─ domain
     │        ├─ dto
     │        ├─ config
     │        ├─ handler
     │        ├─ filter
     │        └─ util
     └─ resources
         ├─ application.yml
         ├─ static
         └─ templates

controller

요청 들어오는 입구. HTTP 요청 파싱하고, 응답 만들어서 내보낸다. 여기서 로직 하면 안 된다. 여기서 로직하면 100% 프로젝트 성장할 때 폭발한다. controller는 사람이 들어오면 안내 데스크에서 어디 가라고 보내주는 역할이다.

service

여기가 로직의 집. “이 기능은 이렇게 흘러가야 한다”라는 규칙, 비즈니스 처리, 트랜잭션 관리 같은 것들. controller는 손님 안내하고, service는 실제 일 한다. controller에다가 로직 넣기 시작하면 프로젝트가 6개월 후 곰이 된다.

repository

데이터베이스 접근하는 애들. select, insert 등 영속성 처리. service는 repository를 부른다. 마치 “야 DB야 이것 좀 가져와봐” 같은 느낌. 여기서 데이터 처리 직접 하면 controller, service가 더러워진다.

domain

Entity가 여기에 있다. 실제 프로그램이 표현하는 핵심 모델. 진짜 주인공.
예: Member, Order, Product
도메인은 그 프로젝트 자체의 개념 세계관이다.
“세상에 Member라는 존재가 있고, 그 Member는 이름을 가진다.” 이런 것.

dto

데이터 전달용. 요청/응답 전송.
도메인 객체 그대로 밖으로 노출하면 나중에 구조 바꿀 때 바로 레이저빔 사망이다. dto는 말 그대로 courier(택배 상자)다.
controller ↔ service 사이에서 왔다갔다하는 택배 박스.

config

스프링 설정. 빈 설정, Swagger 설정, CORS 설정, Jackson 설정 등.
이거 안 보이면 오히려 이상하다.

handler

예외 처리 모아두는 곳. @RestControllerAdvice 같은 글로벌 예외 처리.
이거 안 해두면 에러 메시지가 우주 끝까지 날아간다.

filter

Servlet 레벨에서 동작하는 요청 가로채기. 로깅, 인증 토큰 검사 같은 것들. controller보다 더 밖에서 동작한다.
근데 처음엔 빈칸으로 놔둬도 된다.

util

어디에도 넣기 애매한 공통 함수.
근데 여기 남용하면 "모든 걸 util에 넣는 괴물"이 된다. 여기다 무의식적으로 다 넣기 시작하면 공부 망함. 진짜 공통인 것만.