REST에 대한 내용을 다루다가 '계층화'가 언급되어 포스팅해보고자 한다.
우리는 프로젝트를 진행 할 때 Controller, Service, Repository로 나누며, 각 레이어의 역할에 대해 고민하며 코딩하여 서로의 기능을 침범하지 않게 노력한다.
그 이유는 무엇일까? 계층화에 대해 다시 한번 짚어보며 그 필요성을 알게된다면 올바른 방향으로 그 고민을 이어갈 수 있을 것이다.
계층화 아키텍처(Layered Architecture)는 소프트웨어 설계의 한 방식으로, 시스템을 명확하게 구분된 여러 계층(layers)으로 나누어 구성하는 것을 말한다.
'관심사의 분리(Separation of Concerns)'를 위해 각 계층이 특정한 역할과 책임을 가진다.
이것은 계층의 응집도를 높이고 결합도를 낮추어서 시스템의 복잡성을 관리하고, 유지보수성, 확장성, 재사용성을 향상시키는 데 도움을 준다.
관심사: 기능, 역할, 책임 등 프로그램의 특정 측면
상위 계층은 바로 아래의 계층에만 의존하는 형태로 구성된다.
(하위 계층은 상위 계층에 대한 어떤 지식이나 정보가 없는 것!)
예를 들어, 프레젠테이션 계층은 사용자 인터페이스와 브라우저 통신 논리를 처리하는 역할이다.
반면, 비즈니스 계층은 요청과 관련된 특정 비즈니스 규칙을 실행하는 역할(비즈니스 로직 수행)을 담당한다.
프레젠테이션 계층은 고객 데이터를 얻는 방법을 알 거나 걱정할 필요가 없다.
비즈니스 계층을 통해 넘어온 정보를 화면에 표시하기만 하면 되는 것이다.
프로젝트를 진행하며 코드를 구현했던 것을 생각해보면 Controller는 Service의 메서드를 구체적으로 알 필요 없이, 단순히 호출하고 결과값을 반환받기만 하면 되는 것이다.
이로써 각 계층은 각자의 역할에만 집중 할 수 있게 되는 것이다.
...
@PostMapping("/auth/signup")
public ResponseEntity<ApiResponse> signupAsync(
@Valid @RequestBody SignupRequestDto signupRequestDto,
HttpServletResponse response) {
userService.signup(signupRequestDto);
String loginId = signupRequestDto.getLoginId();
Cookie cookie = emailAuthService.getCookieByLoginId(loginId);
response.addCookie(cookie);
return ResponseEntity.ok(new ApiResponse<>("인증 번호를 입력해주세요.", HttpStatus.OK.value()));
}
...
전형적으로 3계층 또는 4계층 아키텍처가 있는데, 나의 경우에는 3계층을 주로 이용했다.
프레젠테이션은 Controller, 비즈니스는 Service, 데이터 엑세스는 Repository 라고 볼 수 있다..
이러한 장점이 있지만, 각 계층을 만들어놓고 로직을 제대로 분리하지 않는다면 계층화를 수행하는 의미가 퇴색 될 수 있다.
나 또한 개발을 처음 시작했을 때는 Service 계층에서 Dto로 변환하여 Controller로 보내는 등, 각 계층의 역할을 제대로 나누지 못했었다.
항상 각 계층의 역할에 대해 고민하며 코드를 작성하자!!