Layered Architecture Pattern

Controller

프레젠테이션 계층(Presentation Layer)

프레젠테이션 계층(Presentation Layer)은 3계층 아키텍처 패턴에서 가장 먼저 클라이언트 요청(Request)을 만나게 되는 계층이며, 컨트롤러가 이 역할을 담당한다

• 하위 계층(서비스 계층, 저장소 계층)에서 발생하는 예외(Exception)을 처리한다.
• 클라이언트가 전달한 데이터에 대해 유효성을 검증하는 기능을 수행한다.
• 클라이언트의 요청을 처리한 후 서버에서 처리된 결과를 반환(Response) 한다.

컨트롤러(Controller)

컨트롤러(Controller)란 클라이언트의 요청(Request)을 처리하고, 서버에서 처리된 결과를 반환(Response)하는 역할을 담당합니다.

• 클라이언트의 요청을(Request) 수신한다.

• 요청에 들어온 데이터 및 내용을 검증한다.

• 서버에서 수행된 결과를 클라이언트에게 반환(Response)한다.

  ---

service

서비스 계층(Service Layer)

서비스 계층(Service Layer), 다른 이름으로는 비즈니스 로직 계층(Business logic layer)은 아키텍처의 가장 핵심적인 비즈니스 로직을 수행하고 클라이언트가 원하는 요구사항을 구현하는 계층이다.

• 프레젠테이션 계층과 데이터 엑세스 계층 사이에서 중간 다리 역할을 하며, 서로 다른 두 계층이 직접 통신하지 않도록 만들어 준다.
• 서비스는(Service)는 데이터가 필요할 때 저장소(Repository)에게 데이터를 요청한다.
• 어플리케이션의 규모가 커질수록, 서비스 계층의 역활과 코드의 복잡성도 점점 커진다.
• 어플리케이션의 핵심적인 비지니스 로직을 수행하며 클라이언트의 요구사항을 반영하여 원하는 결과를 반환 해주는 계층이다.

서비스 계층의 장단점

서비스 계층의 장점

• 사용자의 유즈케이스와 워크플로우를 정확하게 정의하고 이해할 수 있도록 도와준다.
• 비지니스 로직이 API뒤에 숨겨져 있으므로, 서비스 계층의 코드를 자유롭게 수정하거나 리펙토링 할 수 있다.
• 저장소 패턴 및 가짜 저장소와 조합하면 높은수준의 테스트를 작성할 수 있다.

서비스 계층의 단점

• 서비스 계층 또한 다른 추상화 계층이므로 잘못 사용하면 코드의 복잡성의 증가 시킬 수 있다.
• 한 서비스 계층이 다른 서비스 계층에 의존하는 경우, 의존성 관리가 복잡해질 수 있다.
• 서비스 계층에 너무 많은 기능을 넣으면 빈약한 도메인 모델과 같은 안티 패널턴이 생길 수 있다.

---

Repository

저장소 계층(Repository Layer)

저장소 계층(Repository Layer)은 데이터 엑세스 계층(Data Access Layer)이라고도 불리며, 주로 데이터베이스와 관련된 작업을 처리하는 계층이다.

• 데이터 접근과 관련된 세부 사항을 숨기는 동시에, 메모리상에 데이터가 존재하는 것처럼 가정하여 코드를 구현하게 됩니다.
• 저장소 계층을 도입하면, 데이터 저장 방법을 더욱 쉽게 변경할 수 있고, 테스트 코드 작성시 가짜 저장소를 제공하기가 더 쉬워집니다.
• 어플리케이션의 다른 계층들은 저장소의 세부 구현 방식에 대해 알지 못하더라도 해당 기능을 사용할 수 있다.즉, 저장소 계층의 변경 사항이 다른 계층에 영향을 주지 않는다.
• 저장소 계층은 데이터 저장소를 간단히 추상화한 것으로, 이 계층을 통해 모델 계층과 데이터 계층을 명확하게 분리할 수 있다.
• 대표적인 저장소 계층의 메서드
  • add(), create() : 새 원소를 저장소에 추가합니다.
  • get(), find() : 이전에 추가한 원소를 저장소에서 가져옵니다.

저장소 계층의 장단점

저장소 계층의 장점

• 데이터 모델과 데이터 처리 인프라에 대한 사항을 분리했기 때문에 단위 테스트(Unit test)를 위한 가짜 저장소(Mock Repository)를 쉽게 만들 수 있다.
• 도메인 모델을 미리 작성하여, 처리해야 할 비즈니스 문제에 더 잘 집중할 수 있게 된다.
• 객체를 테이블에 매핑하는 과정을 원하는 대로 제어할 수 있어서 DB 스키마를 단순화할 수 있다.
• 저장소 계층에 ORM을 사용하면 필요할 때 MySQL과 Postgres와 같은 다른 데이터베이스로 쉽게 전환할 수 있다.

저장소 계층의 단점

• 저장소 계층이 없더라도 ORM은 모델과 저장소의 결합도를 충분히 완화시켜 줄 수 있다
  -> ORM이 없을 때 대부분의 코드는 Raw Query로 작성되어 있기 때문입니다.

• ORM 매핑을 수동으로 하려면 개발 코스트가 더욱 소모된다.
  -> 여기서 설명하는 ORM은 저희가 이전에 사용한 Prisma와 같은 라이브러리를 말합니다.