[Java] Spring MVC와 레이어드 아키텍처에 대한 정리

 

1. MVC 패턴

Model - View - Controller

 

소프트웨어 개발에는 디자인 패턴이라는 개념이 있다.

필요한 기능에 대한 코드를 무턱대고 만드는것이 아니라,

일정한 형식이나 패턴에 맞게 코드를 만들어서 기능을 구현해야 한다.

이를 '관심사의 분리'라고 한다. 

관심사가 분리되면 각 기능별 수정이 필요할때, 전체 코드를 고칠 필요 없이 해당 관심사에 관련된 코드만 수정하면 된다.

 

웹 사이트 개발을 백엔드(서버) / 프론트엔드(클라이언트)로 나누면,

백엔드 개발자가 Java의 Spring / Spring boot 프레임워크를 사용할때 주로 MVC 패턴을 활용한다.

 

[mvc 패턴 흐름도]

 

• 모델 (Model)

       - 데이터 담당 계층

• 뷰 (View)

      - 사용자가 보는 인터페이스(UI) 담당 계층.

      - 모델이 처리한 데이터를 받아서 사용자의 브라우저로 렌더링되는 페이지이다.

      - 이쪽 코드에는 데이터에 관련된 코드가 없어야한다. (당연함.. UI 담당 계층임..)

• 컨트롤러 (Controller)

      - 모델과 뷰를 연결하는 담당 계층.

       - 웹 브라우저(클라이언트)를 통해 들어오는 요청을 가장 먼저 처리한다.(ex. url을 요청받으면 관련 api를 호출하는

         코드가 작성되는 부분)

 

---

2. 계층형 구조  (Layered Architecture)

 

 

[스프링 부트 아키텍처 흐름도]

 

1. 레이어드 아키텍처

장점	1. 패키지 구조만 보고 프로젝트의 전체적인 구조를 파악할 수 있다.    - 애플리케이션의 API를 보고 흐름을 파악하고 싶다면, Controller 패키지 하나만 보고 파악할 수 있다.   - 애플리케이션의 비즈니스 로직을 보고 싶다면, Service 패키지 하나만 보고 파악할 수 있다. 2. 계층별 응집도가 높아진다.    - 계층별 수정이 일어날 때, 하나의 패키지만 보면 된다.
단점	1. 도메인별 응집도가 낮다. (패키지로 애플리케이션의 기능을 구분짓지 못한다)   - 도메인의 흐름을 파악하기 힘들다.   - Product 도메인의 흐름을 보고 싶을 때, 모든 계층 패키지를 봐야한다.   -하나의 패키지안에 여러 도메인(상품, 장바구니, 사용자)들이 섞여 있다. 2. 도메인과 관련된 스펙 & 기능이 변경되었을 때, 변경 범위가 크다.    - Product에 대한 변경점이 있을 때, 여러 패키지에서 변경이 일어난다.  3. 유스케이스(사용자의 행위) 표현이 어렵다. 4.규모가 커지면 하나의 패키지 안에 여러 클래스들이 모여서 구분이 어려워진다.

2. 도메인 아키텍처

장점	1.도메인별 응집도가 높아져서 흐름을 파악하기 쉽다.   -Product 도메인의 흐름을 보고 싶을 때, Product 패키지 하나만 보면 된다.   -도메인과 관련된 스펙 & 기능이 변경되었을 때, 변경 범위가 적다.   -Product에 대한 변경점이 있을 때, Product 패키지만 변경이 일어난다.   -유스케이스별로 세분화해서 표현이 가능하다. ex : 상품 등록 유스 케이스 -> RegisterProductService ex : 상품 검색 유스 케이스 -> SearchProductService 도메인별로 패키지가 나뉘기 때문에 product 패키지에서 위와 같은 네이밍으로 분리할 수 있다.
단점	1.애플리케이션의 전반적인 흐름을 한눈에 파악하기가 어렵다.   -흐름을 파악하기 위해 여러 패키지를 왔다갔다 해야할 가능성이 높다.   -개발자의 관점에 따라 어느 패키지에 둘지 애매한 클래스들이 존재한다. Welcome 페이지를 맵핑하는 컨트롤러일 때, 어느 도메인 패키지에 위치할지 개발자에 따라 다를 수 있다. 자신이 예상하는 패키지와 다를 때, 해당 클래스를 찾기가 어렵다.

 

레이어드 아키텍처 4-tier (4계층) 구조는 다음과 같다.

https://www.javatpoint.com/spring-boot-architecture

 

• Presentation Layer

       - MVC 패턴이 여기 속한다.      

       - HTTP 요청을 처리하고, JSON 매개 변수를 객체로 변환하고, 요청을 인증하여 비즈니스 계층으로 전송하는 역할

      - 사용자와의 상호 작용을 담당하는 계층으로, 주로 UI 및 사용자 입력 처리 담당

     

• Business Layer

      - 표현 계층에서 요청을 보내면 DAO 를 이용해서 비지니스 로직을 수행하는 계층이다.

      - DTO (Data Transfer Object) , Domain , Service 

 

• Persistence Layer

      - Model : mvc의 모델과 이름이 같지만 다르다. 

      - 스프링에서 Repository , DAO(Data Access Object)가 이 계층에 속함

      - 주로 사용자 인터페이스와 상호작용하는 데 필요한 data를 나타낸다.

      - 화면에 표시되는 데이터를 담고있는 객체를 의미.

• Data Access Layer

      -   CRUD(저장, 검색, 수정, 삭제) 작업이 수행되는 계층

      -  DB와 상호작용 담당 부분으로 JDBC, Mybatis, JPA를 사용해서 구현함

    

 

 

---

3. Spring MVC와 Layered Architecture의 결합

Spring MVC는 주로 Presentation Layer에 해당하며, 비즈니스 로직은 Business Logic Layer에서 처리된다.

이렇게 계층화된 아키텍처를 사용하면 각 계층이 독립적으로 유지되므로 유지보수, 테스트, 확장이 용이해진다.

 각 계층 간의 의존성이 낮아져 시스템이 더 모듈화되고 유연해진다는 장점이 있다.

 

 

 

 

- 참고 사이트

스프링 부트 아키텍처 - javatpoint

Spring Boot Architecture - javatpoint

 

https://ksh-coding.tistory.com/96?category=1107116

[아키텍쳐] 패키지 구조 : 계층형 VS 도메인형 어떤 것을 선택할까?

 

쉽게 말하는, 계층형 아키텍처의 문제 (velog.io)

쉽게 말하는, 계층형 아키텍처의 문제