목차
▼ What ?
"악쓰는하마"라는 노래방 키오스크의 백엔드 서비스를 만들어보는 토이 프로젝트를 하기 전에 일단 스프링 부트의 패키지 구조에 대해 공부해보고, 계층형 구조와 도메인형 구조 중 어떤 구조에 따라 해당 프로젝트를 진행해야 할지도 함께 생각해보려고 한다.
▼ 스프링 부트 패키지 구조
MVC 패턴에 따른 스프링에서의 흐름
- 클라이언트(~View)에서 서버로 요청을 보낸다.
- 요청을 받은 Controller에서 '비즈니스 로직'에 해당하는 Service에 요청을 보낸다.
- Service에서 요청받은 비즈니스 로직을 처리하는데,
그 과정에서 DB에 저장된 데이터가 필요하다면 DAO(~Repository)를 통해 DB에 접근해야 한다.
(이전까진 DTO를 통해 계층 간의 요청/응답이 이루어진다.) - DAO는 쿼리문을 이용한 트랜잭션을 실행시켜 DB에 접근한다.
계층형 구조(by Layer) & 도메인형 구조(by Domain)
- 첨부 사진을 살펴보면 계층형 구조가 무엇이고, 도메인형 구조가 무엇인지 금방 파악할 수 있다.
- 계층형 구조(by Layer)
: 스프링의 각 계층에 해당하는 Entity, Controller, Service, Repsitory 같은 클래스들을 기준으로 디렉터리를 생성하는 것이다.
(첨부한 사진 참고) - 도메인형 구조(by Domain)
: 도메인, 즉 엔티티(Entity)별로 패키지를 분류하여 생성한 구조이다.
- 계층형 구조(by Layer)
▼ 계층형 vs 도메인형
어떤 구조를 선택하는 것이 맞을까?
- 계층형 구조는 프로젝트의 구조를 쉽게 파악할 수 있다는 장점이 있다.
하지만, 규모가 큰 서비스일 수록 한 디렉터리 안에 너무 많은 클래스들이 쌓여 구분이 어려워진다.
패키지 간의 결합도가 커져 코드를 수정할 때 어떤 하나의 기능을 수정하기 위해 여러 패키지를 고려해야 한다는 번거로움도 있다.
도메인별 응집도가 낮아 '도메인(회원, 상품, 배송)'과 관련된 기능을 수정해야 할 경우엔 수정 범위가 매우 커질 수 있다 !
(반대로, 계층별 응집도가 높다는 측면에서 계층 단위의 수정을 하는 경우엔 용이한 구조라고 볼 수 있다.)
[GDSC] 북 스터디 : 05_책임과 메시지
▼ What ? 다섯 번째 챕터인 "책임과 메시지"에서 중요한 키워드는 '자율적인 객체'과 '메시지'인 것 같다. 왜 객체지향 시스템이 다른 패터다임보다 더 뛰어나다고 평가받는지, 그리고 그러한 객
ukym-tistory.tistory.com
- 도메인형 구조는 프로젝트의 전체적인 구조를 파악하는데 높은 이해도를 요구한다는 단점이 있다.
하지만, 계층형 구조와 달리 도메인을 기준으로 패키지를 분리하여 생성하기 때문에 유지 · 보수 및 변경 사항 적용 등의 경우엔 보다 직관적인 작업이 가능하다. 그리고 '핵심' 도메인별로 패키지를 분류하게 되면 패키지들 간의 결합도를 줄이는 데 유리하기 떄문에 어떻게 보면 객체지향적인 면에서 더 적합하다고 생각한다.
➙ 도메인형 구조가 잦은 업데이트가 필요한 실무에서 계층형 구조보다 선호되는 프로젝트 패키지 구조인 이유인 것 같다 !
이번 토이 프로젝트에선 어떤 구조를?
- 사실 프로젝트의 패키지 구조에 정답은 없다고는 하나, 진행하려는 프로젝트 혹은 개발하려는 서비스에 따라 더 적합한 패키지 구조는 있을 수 있다고 생각한다.
- 이번에 진행할 "악쓰는 하마"라는 노래방의 키오스크 구현 프로젝트는 규모가 크지 않기도 하고 혼자 진행하는 프로젝트이다.
➙ 패키지 간의 결합도가 프로젝트에 영향을 끼칠 수 있는 부분이 적어 '계층형 구조'의 단점이 상쇄될 것이고, 코드 리뷰를 받기 위한 목적으로 진행하는 프로젝트이기도 해서 전체적인 구조를 쉽게 파악할 수 있는 '계층형 구조'로 코드를 작성하는 것이 더 적합할 것 같다!
(하지만, 대개의 실무에선 '도메인형 구조'를 따르기 때문에 이번 토이 플젝을 통해 '도메인형 구조'를 설계하는 경험을 해보는 것이 더 괜찮을 것 같기도 하다.)
▼ What ?
"악쓰는하마"라는 노래방 키오스크의 백엔드 서비스를 만들어보는 토이 프로젝트를 하기 전에 일단 스프링 부트의 패키지 구조에 대해 공부해보고, 계층형 구조와 도메인형 구조 중 어떤 구조에 따라 해당 프로젝트를 진행해야 할지도 함께 생각해보려고 한다.
▼ 스프링 부트 패키지 구조
MVC 패턴에 따른 스프링에서의 흐름
- 클라이언트(~View)에서 서버로 요청을 보낸다.
- 요청을 받은 Controller에서 '비즈니스 로직'에 해당하는 Service에 요청을 보낸다.
- Service에서 요청받은 비즈니스 로직을 처리하는데,
그 과정에서 DB에 저장된 데이터가 필요하다면 DAO(~Repository)를 통해 DB에 접근해야 한다.
(이전까진 DTO를 통해 계층 간의 요청/응답이 이루어진다.) - DAO는 쿼리문을 이용한 트랜잭션을 실행시켜 DB에 접근한다.
계층형 구조(by Layer) & 도메인형 구조(by Domain)
- 첨부 사진을 살펴보면 계층형 구조가 무엇이고, 도메인형 구조가 무엇인지 금방 파악할 수 있다.
- 계층형 구조(by Layer)
: 스프링의 각 계층에 해당하는 Entity, Controller, Service, Repsitory 같은 클래스들을 기준으로 디렉터리를 생성하는 것이다.
(첨부한 사진 참고) - 도메인형 구조(by Domain)
: 도메인, 즉 엔티티(Entity)별로 패키지를 분류하여 생성한 구조이다.
- 계층형 구조(by Layer)
▼ 계층형 vs 도메인형
어떤 구조를 선택하는 것이 맞을까?
- 계층형 구조는 프로젝트의 구조를 쉽게 파악할 수 있다는 장점이 있다.
하지만, 규모가 큰 서비스일 수록 한 디렉터리 안에 너무 많은 클래스들이 쌓여 구분이 어려워진다.
패키지 간의 결합도가 커져 코드를 수정할 때 어떤 하나의 기능을 수정하기 위해 여러 패키지를 고려해야 한다는 번거로움도 있다.
도메인별 응집도가 낮아 '도메인(회원, 상품, 배송)'과 관련된 기능을 수정해야 할 경우엔 수정 범위가 매우 커질 수 있다 !
(반대로, 계층별 응집도가 높다는 측면에서 계층 단위의 수정을 하는 경우엔 용이한 구조라고 볼 수 있다.)
[GDSC] 북 스터디 : 05_책임과 메시지
▼ What ? 다섯 번째 챕터인 "책임과 메시지"에서 중요한 키워드는 '자율적인 객체'과 '메시지'인 것 같다. 왜 객체지향 시스템이 다른 패터다임보다 더 뛰어나다고 평가받는지, 그리고 그러한 객
ukym-tistory.tistory.com
- 도메인형 구조는 프로젝트의 전체적인 구조를 파악하는데 높은 이해도를 요구한다는 단점이 있다.
하지만, 계층형 구조와 달리 도메인을 기준으로 패키지를 분리하여 생성하기 때문에 유지 · 보수 및 변경 사항 적용 등의 경우엔 보다 직관적인 작업이 가능하다. 그리고 '핵심' 도메인별로 패키지를 분류하게 되면 패키지들 간의 결합도를 줄이는 데 유리하기 떄문에 어떻게 보면 객체지향적인 면에서 더 적합하다고 생각한다.
➙ 도메인형 구조가 잦은 업데이트가 필요한 실무에서 계층형 구조보다 선호되는 프로젝트 패키지 구조인 이유인 것 같다 !
이번 토이 프로젝트에선 어떤 구조를?
- 사실 프로젝트의 패키지 구조에 정답은 없다고는 하나, 진행하려는 프로젝트 혹은 개발하려는 서비스에 따라 더 적합한 패키지 구조는 있을 수 있다고 생각한다.
- 이번에 진행할 "악쓰는 하마"라는 노래방의 키오스크 구현 프로젝트는 규모가 크지 않기도 하고 혼자 진행하는 프로젝트이다.
➙ 패키지 간의 결합도가 프로젝트에 영향을 끼칠 수 있는 부분이 적어 '계층형 구조'의 단점이 상쇄될 것이고, 코드 리뷰를 받기 위한 목적으로 진행하는 프로젝트이기도 해서 전체적인 구조를 쉽게 파악할 수 있는 '계층형 구조'로 코드를 작성하는 것이 더 적합할 것 같다!
(하지만, 대개의 실무에선 '도메인형 구조'를 따르기 때문에 이번 토이 플젝을 통해 '도메인형 구조'를 설계하는 경험을 해보는 것이 더 괜찮을 것 같기도 하다.)
