목차
스프링 프로젝트 구조
스프링은 역할에 따라 코드를 분리한다. 보통 Controller, Service, Entity, Repository 이렇게 4개의 코드로 분리하는데, 이 구조를 레이어드 아키텍처(계층형 아키텍처)라고 부른다.
역할에 따라 코드를 분리하는 이유
역할에 따라 코드를 분리하는 이유는, 역할을 분리함으로서 각 코드의 책임이 명확해지고, 그에 따라 한 곳을 수정해도 다른 코드에 미치는 영향을 줄일 수 있기 때문이다.
예를들어, Repository(저장소)를 메모리에서 데이터베이스로 바꾸어도, 다른 코드들은 수정할 필요가 없다.
각 코드별 역할
각 코드는 무엇을 담당하는 것인지 요리에 비유를 들어 쉽게 설명하자면,
- Controller(컨트롤러) = 서빙
Controller는 클라이언트가 요청한POST /items,GET /items와 같은 API 엔드포인트가 도착하는 진입점이다. 클라이언트의 요청이 유효한지 컨트롤러에서 검사하고 응답을 반환해주는 역할을 한다.
즉, 실제 일은Service에게 시키고,Controller는 전달받은 일이 유효한지를 검사하고 일을 마쳤을때 결과를 반환하는 역할을 한다.
컨트롤러는서빙을 담당하는 직원이다.
- Service(서비스) = 셰프
Service는 컨트롤러에서 전달받은 일을 직접 수행하는 역할이다. 서비스 내에서도 어떤 규칙을 지켜야할지 인터페이스로 구현을 하기도 한다.
서비스는메인 셰프의 역할을 한다.
-
Repository(리포지토리) = 창고
Repository는 저장소로서 데이터베이스와 데이터를 주고받는 역할을 한다.
저장소의 규칙을 나타내는 인터페이스를 정의하며, 테스트를 하기위한 메모리영역, 실제 실무에서 적용할 데이터베이스 등을 관리한다.
리포지토리는식량 창고와 같은 역할을 한다.
-
Dto = 주문서/영수증
Dto는 컨트롤러와 서비스 사이의전용 양식과 같은 역할을 한다.
Dto는 보통RequestDto,ResponseDto로 나뉘어져 있으며 각각 클라이언트에게서 받는 요청과 클라이언트에게 보낼 응답 데이터에 대한 양식을 설계해준다.
즉,주문서와영수증이라고 생각하면 편하다.
- Entity(엔티티) = 식량
Entity는 서버의 자원을 정의하는 코드이다. 쉽게 말하면, 데이터베이스의 테이블과 매핑되는 객체이다. 예를들어, 상품의 정보를 정의하고 싶다면, 엔티티에서Item.java와 같이 코드를 작성하고 그 상품에 대한 정보(id,name,price)등을 정의해주는 역할을 한다. 리포지토리가 데이터베이스와 통신할때 이 객체를 사용한다.
엔티티는식량그 자체라고 생각하면 편하다.
스프링 서버의 데이터 흐름
처음 이 내용을 접하면 복잡해보이지만, 데이터가 흐르는 순서는 명확하다.
POST /items를 실행하였을때 어떻게 데이터가 흐르는지 식당에 비유하여 설명해보자면,
- 홀에서 [Request]주문 접수
1)Client: 주문서에 '파스타'를 달라고 주문POST /items하여컨트롤러에게 전달한다.
2)Controller: 주문을 받고 주문서(ItemRequestDto)에 문제가 없는지 검사한다. 이 과정에서 상품이름이 비어있거나 가격이 맞는가 등을 검사한다.
3)Controller: 주문서(ItemRequestDto)를 들고 메인 셰프인Service에게 전달한다.
- 주방에서 [Processing] 요리 시작
1)Service: 주문서를 보고 실제 상품 정보(Entity)를 생성한다.
2)Service: 완성된 식량(Entity)를 식량창고(Repository)에게 전달한다.
3)Repository: 식량창고(Repository)에 식재료(Entity)를 보관하고, 저장된 결과를Service에게 반환한다.
- 주방에서 홀로 [Response] 서빙
1)Service: 식재료(Entity)에 대한 작업을 끝내고 영수증(ItemResponseDto)을Controller에게 반환한다.
2)Controller: 영수증과 주문 성공(201 Created)했다는 정보를 손님(Client)에게 전달해준다.
전체 흐름을 요약해보자면 Client -> Controller -> Service -> Repository -> Service -> Controller -> Client 순으로 흘러가는것을 알 수 있다.
이처럼 역할별로 책임을 나누면 코드를 작성하는것에 있어서 유지보수와 확장이 쉬워진다.
