[아키텍쳐] Service, Repository가 왜 필요할까?

🎯 0. 주제 선정 이유

하나의 애플리케이션을 만들 때

자연스럽게 Controller, Service, Repository, Dao를 나누고 시작하는 경우가 많았다.

Controller는 HTTP 요청 및 응답을 처리하는 가장 앞 단이기 때문에 자연스럽게 존재해야했고

Dao는 DB와 연결해서 데이터를 영속화하기 위해 필요한 것이 자연스러워보였다.

 

하지만, Service와 Repository는 왜 필요한지 이유를 정확히 알지 않고 관성적으로 쓰는 경우가 많았다.

 

그래서 Layered Architecture를 공부한 지금,

왜 Service, Repository가 필요한지 내 생각을 정리해보려고 한다.

 

우테코 미션에서 경험해보면서 생긴 나의 생각을 정리해보겠다!

(주관적인 내용이라 틀린 부분이 있을 수 있다! 😂)

 

이전 Layered Architecture 포스팅

https://ksh-coding.tistory.com/92

[아키텍쳐] Layered Architecture란? (feat. 자동차 경주 미션 예시)

---

🎯 1. 웹 애플리케이션에서의 관심사(책임)들

 

우선 웹 애플리케이션에서 HTTP 요청 & 응답을 처리하기 위해 필요한 ‘관심사(책임)’을 나열해보자.

1. HTTP 요청 & 응답 변환 책임 (직렬화/역직렬화 : 데이터 포맷 <-> 자바 객체 변환)
2. 자동차 경주 비즈니스 로직 수행 책임
3. 도메인 <-> DB 전달 객체(DTO, Entity)로 변환 책임
4. DB CRUD 수행 책임

 

위의 관심사들을 적절히 계층별로 나누면서 아키텍쳐가 구성된다. 

 

계층의 발전 과정을 살펴보면서 Service, Repository의 필요성을 발견해보자.

---

🎯 2. 계층 구조 발전 과정

 

먼저 Service, Repository 계층이 없던 Controller-Dao 2계층 구조를 보자.

 

🎯 2-1. Controller + Dao 2계층

해당 구조에서는 관심사를 DB를 기준으로 크게 2가지로 분리한다.

• Controller : DB 관련 이외의 책임
  • HTTP 요청 & 응답 변환 책임 (직렬화/역직렬화 : 데이터 포맷 <-> 자바 객체 변환)
  • 비즈니스 로직 수행 책임
  • 도메인 <-> DB 전달 객체(DTO, Entity)로 변환 책임
• Dao : DB 관련 책임
  • DB CRUD 수행 책임

Dao는 Layered Architecture의 핵심인 ‘관심사의 분리’가 잘 이루어졌다.

하지만, Controller는 너무 많은 책임을 가지고 있는 것을 한 눈에 봐도 알 수 있다.

 

관심사의 분리가 되지 않으면

1차적으로는 눈에 보이는 코드량이 많아지고,

변경에 영향을 받는 범위가 넓어져서 유지보수성이 떨어진다.

 

이러한 Controller의 책임을 확실하게 분리하고자 하는 목적으로 나타난 계층이 Service로 생각된다.

 

 

🎯 2-2. Controller + Service + Dao 3계층

 

이전의 Controller에서는 HTTP 요청 & 응답, 도메인, DB 전달 객체를 관리하는 책임을 가졌다.

이러한 책임에서 Service 계층을 추가함으로써

애플리케이션의 제일 앞 단으로 HTTP 요청 & 응답 만 관리하는 책임을 가지고,

나머지 책임들은 Service 에서 가지게 했다.

 

여기서의 핵심은 Controller의 책임을 HTTP 요청 & 응답 만 관리하는 책임으로 분리했다는 것이다!

 

• Controller : DB 관련 이외의 책임
  • HTTP 요청 & 응답 변환 책임 (직렬화/역직렬화 : 데이터 포맷 <-> 자바 객체 변환)
• Service : 비즈니스 로직 수행 책임
  • 자동차 경주 비즈니스 로직 수행 책임
  • 도메인 <-> DB 전달 객체(DTO, Entity)로 변환 책임
• Dao : DB 관련 책임
  • DB CRUD 수행 책임

 

이 구조에서는 이전 구조의 문제였던 Controller의 관심사 분리가 잘 이루어졌다.

 

따라서, Controller에서는 도메인 및 DB 전달 객체 에 대한 로직을 모르게 되었고,

HTTP 요청 & 응답에 관련된 책임만 가지게 되었다.

 

이로 인해 Controller 계층의 코드량도 줄고, 응집도가 높아져 유지보수성이 높아졌다.

HTTP 요청 & 응답에 관한 책임을 유지보수한다면 Controller 계층만 보면 되는 것이다!

 

Controller는 이전 구조에 비해 관심사의 분리가 정확히 됐지만,

새로 생긴 Service에서는 2가지 책임을 가진 것을 볼 수 있다.

현재 구조에서 Service는 도메인을 관리하여 비즈니스 로직을 수행하는 것과,

Dao에 전달하기 위한 DB 관련 객체(DTO, Entity)까지 관리해야했다.

 

이러한 Service의 책임을 확실하게 분리하고자 하는 목적으로 나타난 계층이 Repository로 생각된다.

 

 

🎯 2-3. Controller + Service + Repository + Dao 4계층

이전의 Controller의 관심사 분리를 위해 Service를 추가했듯이,

Repository는 Service의 관심사 분리를 위해 등장한 계층이라고 생각된다.

 

Repository를 추가함으로써

Service 계층은 도메인만 관리하여 비즈니스 로직을 수행하는 책임만 가지게 되었다.

DB에 전달하는 객체의 관리 책임은 Repository가 가지게 되었다.

 

• Controller : DB 관련 이외의 책임
  • HTTP 요청 & 응답 변환 책임 (직렬화/역직렬화 : 데이터 포맷 <-> 자바 객체 변환)
• Service : 비즈니스 로직 수행 책임
• Repository : 도메인 <-> DB 전달 객체(DTO, Entity)로 변환하여 Service와 상호작용 책임
• Dao : DB CRUD 수행 책임

---

🎯 3. 결론 및 요약

결국 Service 와 Repository 가 필요한 이유는, ‘관심사의 분리’ 측면에서 필요했다고 느꼈다.

하나의 계층은 하나의 관심사만 가져야하는데,

Service와 Repository가 없는

Presentation Layer(Controller)는 관심사가 여러 개였다.

 

그래서 각 Layer 간의 관심사를 하나로 줄여서

Layer의 응집도를 높여 유지보수성을 높이는 효과를 얻기 위해

Service와 Repository가 필요한 것이었다.

 

Service와 Repository도  결국 Layered Architecture에서 계층이 추가된 것이기 때문에,

 Layered Architecture에서 '계층을 추가하는 이유'와 같은 것을 알 수 있었다.