패키지 구조 설계를 맡게 되었고, 구조에 대해 조사하다가 알게된 내용들이다.
패키지 구조는 도메인별 구조와 계층별 구조로 크게 두가지로 나뉜다. 그외에도 프로젝트에 따라 커스텀하게 패키지 구조를 설계하기도 한다.
각 구조에 대해 이해하기 위해 도메인과 계층에 대해 조사해보았고, 결론적으로 계층형 구조를 채택하였다.
두 구조 모두 장단점을 가지고 있는대
1. 도메인별 구조
- 장점
- 도메인별 응집도가 높다. 도메인의 흐름을 파악하기 쉽고 도메인에 관한 변경사항에 대해 변경 범위가 좁다
- 유스케이스별로 세분화해서 표현이 가능하다
- 단점
- 어플리케이션 전반적인 흐름의 파악이 어렵고 도메인 영역이 애매한 클래스들이 존재하기 때문에 이런 부분에 대한 고려가 필요하다.
2. 계층형 구조
- 장점
- 프로젝트 전반적인 흐름을 파악하기 쉽고 계층별 응집도가 높아진다. 계층별 변경사항에 대해 변경 범위가 좁다
- 단점
- 도메인별 응집도가 낮고 규모가 커지면 하나의 패키지안에 여러 클래스들이 모여 구분이 어렵다.
간단하게 다음과 같이 정리 할 수 있을것이다.
지금 진행하는 프로젝트의 경우 소규모에 팀원들 모두 첫 프로젝트였다. 또한 팀의 도메인에 대한 이해도 역시 부족한편이다. 도메인형 패키지구조를 채택하였을 경우 스프링 웹 계층이 아닌 DDD 계층 구조를 바탕으로 패키지 구조를 설계할텐데, 현 상태에서는 학습하고 설계하는대 투자되는 시간이 너무 많아질 가능성이 크기에 계층별 구조를 채택하게 되었다.
다음은 계층별 패키지 구조를 설계 할때 바탕이 된 스프링 웹 계층이다
왼쪽은 실제 우리 프로젝트의 패키지 구조이다. 예외처리기는 커스텀 예외와 함께 Exception 패키지에서 관리하고, 필터는 Config 패키지에서 관리하고 있다.
1. Web Layer
웹 계층은 뷰, 컨트롤러, 필터나 예외처리기 같이 외부 요청과 응답에 대한 전반적인 영역이다. 어플리케이션의 진입점이기 때문에 다른 레이어에서 발생한 예외를 처리하거나 인증을 관리하고 권한없는 사용자의 인가를 거부하는 역할도 한다.
DTO ( Data Transfer Object ) 라고 불리는 데이터 전송 객체를 통해 데이터를 주고 받는다.
우리는 컨트롤러에서 파라미터를 검증하는 역할만 수행할 수 있도록 하였다. 이렇게 해서 서비스 계층의 부담을 덜고 컨트롤러의 역할을 명확히 하였다.
2. Service Layer
서비스 계층은 웹 계층으로부터 DTO를 전달받는다. 전달받은 DTO를 가공 및 처리하거나 트랜젝션 처리를 주로 한다.
우리는 서비스 계층에 비즈니스 로직을 구현하였다. 아직 도메인 모델에 대한 이해도가 부족하고 VO나 도메인 서비스등 까지 고려하면 프로젝트가 상당히 방대해질것으로 예상되었다. 비즈니스로직까지 처리하게되어 비대해진 서비스 계층의 부담을 덜고자 위해 컨트롤러에서 서비스로 넘길 매개변수에 대한 유효성 검사는 컨트롤러에서 마치고, 서비스에서는 하지 않기로 하였다. 물론 레파지토리 계층에서 넘어온 엔티티에 대한 검사는 해야한다.
3. Repository Layer
레파지토리 인터페이스 및 그 구현체들이 이 계층에 위치한다. 데이터베이스에 접근 하는 영역이며 도메인 모델을 통해 서비스 계층과 데이터를 주고 받는다. 엔티티를 매개변수로 받고, 마찬가지로 엔티티를 서비스 계층으로 반환한다.
여기서 주고 받는 엔티티는 아무래도 데이터베이스와 밀접하게 관계하기때문에 취급하는대 좀 주의를 기울여야 했다. 그래서 Setter를 사용하지 않고,엔티티 내부에 수정 메서드를 작성하여 값을 변경해도 되는 필드의 값만 변경 할 수 있도록 하여 일관성을 유지할 수 있도록 하였다.
외에도 Mapper 패키지와 Util 패키지를 따로 구성하였는대, Mapper에서는 Dto와 엔티티간의 변환 작업을 수행하는 클래스를 관리하고, Util패키지에서는 유효성검사나 난수생성등 여러 클래스에서 공통적으로 사용되는 로직을 추출하여 클래스로 만들고 Util패키지에서 관리하도록 하였다.
'두썸띵 > 팀 - 여행플래너' 카테고리의 다른 글
여행 플래너 사이트 비교 (1) | 2024.11.29 |
---|