데이터의 흐름 또는 코드가 책임지는 부분의 유사도에 따라서 계층별로 나누어서 대규모 웹 어플리케이션을 구현한다. 이때의 이점은 각 계층이 담당하고 있는 책임을 알 수 있기 때문에 대량의 코드에서도 필요한 부분을 찾아서 수정하기 다소 쉽다. 또한 구조적으로 정리되어 있는 이점이 있다.

웹 어플리케이션을 구현할 때 이러한 계층들에 대한 제대로 된 정의를 가지고 각자가 담당하는 기능을 구현하는 것이 좋다. 함께 일하는 동료 개발자나 이후에 레거시 코드로 받을 다른 개발자들과의 의사소통 비용을 크게 감소하고 쉽게 코드와 구조를 이해할 수 있기 때문이다.

  • 총 5개의 계층이 있다.
1. 프레젠테이션 계층 (Presentation Layer)
2. 제어 계층 (Control Layer)
3. 비지니스 로직 계층 (Business Logic Layer)
4. 퍼시스턴스 계층 (Persistence Layer)
5. 도메인 모델 계층 (Domain Model Layer)

Presentation Layer

  • 식당에서 메뉴판 역할
  • UI를 담당하는 계층이다.
    • User에게 보여지는 화면 담당
    • User의 입력을 받는 담당
    • 입력에 따른 결과를 서버로부터 받아서 다시 화면에 띄우는 담당
  • 다른 계층과의 접촉이 없고 Control layer를 통해서 다른 계층과 협업한다. 따라서 presentation layer의 모든 요청과 응답은 control layer를 통해서 이루어진다.
  • UI에서 직접적인 비지니스 로직을 수행해서 일을 처리하지 않는다!

Control Layer

  • 식당에서 지배원 역할
  • Presentation layer와 비지니스 로직을 담당하는 계층 분리하는 연결 계층이다. UI에서 직접적으로 핵심 비지니스 로직에 접근하지 않도록 UI에서 온 요청에 대해 한차례 필터링 한다.
  • 즉, 사용자 화면에서 온 요청을 분석해서 비지니스 로직에 해당 요청에 대한 처리(핵심적인 일 수행)을 결정하고 그에 따른 결과를 다시 사용자 화면으로 응답한다.
    • 다르게 이해하면, 핵심 비지니스 로직을 처리하는 계층은 어떠한 요청인지, 누구로부터의 요청인지를 알지 못한다.
  • UI 입력 검증, 요청/응답 전달, 예외 핸들링, Domain에서 처리된 로직 뷰와 연결 등의 기능을 담당한다.

Business Layer

  • 식당에서 요리사 역할
  • 핵심 업무를 처리하는 로직을 담당하는 계층이다.
  • 즉, 어플리케이션의 핵심 기능이 어떻게 처리될 것인지에 대한 코드 구현이 모두 포함되어 있다.
  • 웹 어플리케이션의 핵심 부분이기 때문에 다른 요소들(사용자 화면, 연결하는 컨트롤러 등)은 변경이 잦을 수 있지만 비지니스 계층은 핵심 기능의 변경 요청이 있지 않은 이상 대체로 변경되지 않는다.
  • 서버의 주를 이루기 때문에 재사용 가능성이 높고 따라서 잘 설계되어야 한다.
  • Business layer 로직은 다른 계층들과 특별히 더 분리되어 있는 것이 좋다. 그래야 유지보수가 쉽고 응집성이 높아진다.
  • 추가로 Business layer 의 코드는 뷰와 persitence layer(다음 설명 계층) 의 연결고리 역할도 한다.

Persistence Layer

  • 식당에서 재료 역할
  • 데이터 처리를 담당하는 계층으로 CRUD를 담당한다.
  • 관계형 정보를 저장 및 업데이트, 삭제 등등의 역할을 수행하는데, 서버에서 생성되는 정보에 영속성을 부여한다는 측면에서 persistence layer라고 부른다.
  • 반대로 DB에서 가져온 정보를 객체화 하는 역할도 수행한다.

Domain Model Layer

  • 식당에서 그릇 역할
  • 계층 사이에 전달되는 비지니스 객체이다.
  • DTO의 형태로 계층간 전달이 되며 핵심 데이터를 보관하여 전달된다.

[참고자료] : https://postitforhooney.tistory.com/entry/Spring-MVC-패턴에서의-5가지-계층에-대한-정보-퍼옴