팀 단위 Back-End 개발에 앞서, "어떤 구조와 컨벤션을 사용해 프로젝트를 개발해나갈 것인가?"에 대한 결정이 가장 중요했다. 개인적으로 객체지향 언어는 설득의 언어라고 생각한다. SOLID부터 시작해 정말 다양한 원칙들과 패턴, 디자인들이 존재하지만, 각각 장∙단점이 존재하기에 어떤 방법이 정답이라고 이야기할 수는 없다. 결국, 어떤 패턴이든 모델이든 상황에 맞게 적용하는 것이 중요하다.
이번 프로젝트에서 적용될 패턴을 확정하는 데 있어, 기준은 다음과 같았다.
이러한 기준에서 프로젝트엔 다음과 같은 패턴을 적용했다.
MVC 패턴은 디자인 패턴 중 하나로, 하나의 프로젝트를 Model
, View
, Controller
로 구분한다. 실질적으로 클라이언트는 유일하게 Controller
와 직접적으로 소통한다.
DispatcherServlet
은 최초 사용자의 요청을 받고, HandlerMapping
에 의해 요청을 수행할 Controller
를 결정한다. Controller
는 로직 수행 후, ModelAndView
에 가공된 데이터와 JSP를 DispatcherServlet
에게 제공한다. DispatcherServlet
은 ViewResolver
를 통해 View
를 얻고 이를 사용자에게 응답으로 보낸다.
Controller 영역은 역할에 따라 Controller
, Service
, Repository
세 가지 영역으로 다시 한번 구분한다.
RequestDTO
) 수신과 서버의 응답(ResponseDTO
) 송신 처리, 상황에 따라 RequestDTO
를 ServiceDTO
로 변환하는 작업을 수행하는 계층ResponseDTO
를 생성하는 계층Entity
의 저장, 조회를 담당하는 계층.MVC 모델에 더해, 작업을 좀 더 작은 단위로 분리하기 위해 도메인 주도 개발(Domain Driven Design) 패턴을 적용하고자 했다. 하지만 도메인 주도 개발에 대한 명확한 이해와 공감대를 모든 개발자가 가지고 프로젝트를 진행하기에는 시간 상 무리가 있어, 간단하게 MVC 모델을 적용함과 동시에 도메인 별로 패키지를 분리하기로 했다.
담당 업무는 도메인에 따라 나눴으며, 코드 상의 혼선 방지나 작업 진행 사항 파악 등에 이점이 있었다.
QueryDSL
, Swagger
, Security
등 프로젝트에 공통적으로 적용되는 설정관련 Class들이 위치한다.ExceptionHandler
, ResponseMessage
, ErrorMessage
, Static Method
등이 위치한다.도메인 패키지는 6가지로 나뉜다.
requestDTO
) 수신 및 서버의 응답(responseDTO
) 송신ResponseDTO
생성 Entity
의 저장, 조회, 삭제, 최신화 등 DB 관련 로직 수행Entity
<-> DTO
의 변환을 담당하는 객체프로젝트에서 DB에 접근하는 방식은 Spring Boot JPA
를 이용하는 방식과 QueryDSL 혹은 JPQL
을 사용하는 방식으로 나뉜다. 다음과 같은 구조를 채택했다.
출처 확인 불가.. 추후 추가 예정
이에 따라 레포지토리 패키지는 3가지로 나뉜다.
QueryDSL
혹은 JPQL
로 구현할 메소드를 정의한 인터페이스프로젝트 데이터 전송 구조이다. 우선 데이터 반환 양식을 통일하기 위해 모든 Response
는 Response Constructor
를 통해 생성될 수 있도록 했다. Entity
와 DTO
의 변환은 Mapper
에서 담당하도록 하여 책임 소재를 확실히 하였고, 인증/인가는 Filter
에서 처리함으로써 데이터의 신뢰성과 안정성을 높이고자 했다.