Layered Architecture Pattern

01.  도메인(Domain)

==> 개발자 대부분은 비즈니스 프로세스를 개선하거나 자동화하기 위해 일한다. 도메인은 이런 프로세스가 지원하는 활동을 의미한다.

==> 개발자 입장에서 구현해야 할 소프트웨어의 대상이 도메인이 된다.

==> 하나의 도메인은 하위 도메인으로 나눌 수 있다. (하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공)

==> 하위 도메인은 B2B(Business-to-Business), B2C(Business to Consumer)로 나눌 수 있다.

• 도메인 모델(Domain Model)
  ==> 유용한 특성을 포함하는 프로세스나 현상의 지도(Map)을 뜻한다.
  ==> 비즈니스를 수행할 사람이 자신의 비즈니스에 대해 마음속에 가지고 있는 지도와 같다.
  ==> 도메인을 개념적으로 정리한 모델
  ==> 사용할 개체를 기억하기 쉬운 이름(식별자)을 부여해 대상을 쉽게 공유할 수 있게 한다.
  • 도메인 모델링(Domain Modeling)의 종류
    1. 엔티티 (Entitiy)
    2. 값 객체 (Value object)
    3. 도메인 서비스 (Domain service)
• 엔티티(Entitiy)
  ==> 실제 DB 테이블과 연관되어 있는 핵심 클래스이고, 엔티티를 기준으로 테이블이 생성되고 DB 스키마가 변경된다.
  ==> 요청(Request)이나 응답값(Response)으로 전달하는 클래스로 사용하면 안된다.
  ==> 내부의 속성이 변경되더라도 여전히 동일한 엔티티로 남아있다.
  ==> 시간에 따라 변하는 속성이 포함될 수 있다.
  ==> 어떤 요소가 엔티티를 유일하게 식별하는지 정의하는 것 또한 중요하다. (보통 이름이나 참조 번호 등을 사용한다.)

02. 아키텍처 패턴 (Architecture Pattern)

• 아키텍처 패턴?
  • 소프트웨어의 구조를 구성하기 위한 가장 기본적인 토대를 제시한다.
  • 각각의 시스템들과 그 역할이 정의되어 있고, 여러 시스템 사이의 관계와 규칙 등이 포함되어 있다.
  • 검증된 구조로 개발을 진행하기 때문에 안정적인 개발이 가능
  • 도메인이 복잡할수록 모델이나 코드를 더 쉽게 변경할 수 있다는 측면에서 큰 이익을 얻을 수 있다.
• 대표적인 아키텍처 패턴
  • 저장소 패턴 (Repository pattern)
    ==> 영속적인 저장소에 대한 추상화
  • 서비스 계층 패턴 (Service layer pattern)
    ==> 유스 케이스(Usercase)의 시작과 끝을 명확하게 정의하기 위한 패턴
  • 작업 단위 패턴 (Unit of work pattern)
    ==> 원자적 연산을 제공한다.
  • 애그리게이트 패턴 (Aggregate pattern)
    ==> 데이터 정합성을 강화하기 위한 패턴
• 아키텍처 패턴을 도입하기 전에 고민해야 할 부분
  1. 아키텍처 패턴이 주는 이익과 비용에 대해 확실한 이유가 있어야 한다.
  2. 해당하는 아키텍처 패턴을 채택했을 때 어떤 장단점이 존재하는지 명확하게 인지해야 한다.
  3. 여러 계층을 추가하기 위해 들이는 노력과 시간을 트자할 만한 가치가 있을 정도로 어플리케이션과 도메인이 복잡한 경우에만 아키덱처 패턴을 도입해야 한다.
     ==> 도입하기 전 어떠한 문제를 해결하고 싶은것 인지, 어떤 장단점이 존재하는지 확실하게 인지한 상태에서 도입하는 것이 좋다.

03. 계층형 아키텍처 패턴 (Layered Architecture Pattern)

• 계층형 아키텍처?
  • 계층을 분리해서 관리하는 아키텍처 패턴, 현재 가장 흔하게 사용되고 있는 아키텍처 패턴
  • 단순하고 대중적, 비용이 적게 든다는 장점(사실상 표준 아키텍처)
  • 어떤 경우든 계층을 분리해서 유지, 각 계층이 자신의 바로 아래 계층에만 의존하게 만드는 것이 목표
  • 계층화 핵심 ==> 높은 응집도(Cohesion), 다른 계층과의 낮은 결합도(Coupling)
    ==> 상위 계층은 하위 계층을 사용할 수 있지만, 하위 계층은 자신의 상위 계층에 누가 있는지 알 수 없다.
    ==> 예) 데이터 엑세스 계층 (Data Access Layer)은 비즈니스 로직 계층 (Business Logic Layer)에  어떤 코드들이 있는지 알 수 조차 없다.
  • 규모가 작은 어플리케이션의 경우 3개, 크고 복잡한 경우는 그 이상의 계층으로 구성
  • 3계층 아키텍처
    • 프레젠테이션 계층 (Presentation Layer)
    • 비즈니스 로직 계층 (Business Logic Layer)
    • 데이터 엑세스 계층 (Data Access Layer) | 영속 계층 (Persistence Layer)

• 계층형 아키텍처 패턴의 장점
  
  1. 관심사를 분리하여 현재 구현하려는 코드를 명확하게 인지할 수 있다.
  2. 각 계층별로 의존성이 낮아 모듈을 교체하더라도 코드 수정이 용이
  3. 각 계층별로 단위 테스트를 작성할 수 있어 테스트 코드를 조금 더 용이하게 구성할 수 있다.
• 3계층 아키텍처 (3 - Layered Architecture)
   - 처리 과정
  1. Controller : 어플리케이션의 가장 바깥 부분, 요청 / 응답을 처리
  ==> 클라이언트의 요청을 처리 한 후 서버에서 처리된 결과를 반환해주는 역할
  2. Service : 어플리케이션의 중간 부분, 실제 중요한 작동이 많이 일어나는 부분
  ==> 아키텍처의 가장 핵심적인 비즈니스 로직이 수행되는 부분
  3. Repository : 어플리케이션의 가장 안쪽 부분, DB와 맞닿아 있다.
  ==> 실제 DB의 데이터를 사용하는 계층
  
  - 플로우를 기반으로 로직이 수행됨
  1. 클라이언트 (Client)가 요청(Request)을 보냄
  2. 요청(Request)을 URL에 알맞는 컨트롤러(Controller)가 수신 받는다.
  3. 컨트롤러(Controller)는 넘어온 요청을 처리하기 위해 서비스(Service)를 호출
  4. 서비스(Service)는 필요한 데이터를 가져오기 위해 저장소(Repository)에게 데이터를 요청
  5. 서비스(Service)는 저장소(Repository)에서 가져온 데이터를 가공하여 컨트롤러(COntroller)에게 데이터를 넘김
  6. 컨트롤러(Controller)는 서비스(Service)의 결과물(Respose)을 클라이언트(Client)에게 전달

 

04. 컨트롤러 (Controller)

• 컨트롤러 (Controller) 란?
  ==> 클라이언트의 요청을 처리 한 후 서버에서 처리된 결과를 반환해주는 역할
  1. 클라이언트의 요청(Request)을 수신
  2. 요청(Request)에 들어온 데이터 및 내용을 검증
  3. 서버에서 수행된 결과를 클라이언트에게 반환(Response)
• 프레젠테이션 계층 (Presentation Layer) ?
  ==> 대표적으로 Controller로 사용, 사용자가 서버에 요청을 하게되면 가장 먼저 만나게 되는 계층
  • 하위 계층에서 발생하는 예외를 처리
  • 클라이언트가 전달한 데이터에 대해 유효성을 검증하는 기능
  • 클라이언트의 요청을 처리한 후 서버에서 처리된 결과를 반환

05. 서비스 (Service)

• 서비스 계층 (Service Layer) ?
  ==> 비즈니스 로직 계층 (Business logic layer)이라고도 불린다. 가장 핵심적인 비즈니스 로직을 수행하고 실제 사용자(클라이언트)가 원하는 요구사항을 구현하는 계층
  • 프레젠테이션 계층 (Presentation Layer)과 데이터 엑세스 계층 (Data Access Layer) 사이에서 중간 다리 역할을 하며 서로 다른 두 계층이 직접 통신하지 않게 만들어 준다.
  • 데이터가 필요할 때 저장소(Repository)에게 데이터를 요청
  • 핵심적인 비즈니스 로직을 수행하여 클라이언트들의 요구사항을 반영, 원하는 결과를 반환해주는 계층
• 서비스 계층의 장단점
  ==> 장점 (각각의 유스 케이스(UserCase)와 워크플로우(Workflow)를 명확히 정의할 때 도움이 된다.)
  1. 저장소에게 얻을 필요 데이터가 무엇인지 이해할 수 있다.
  2. 어떤 사전 검사와 현재 상태 검증을 필수적으로 해야하는 것인지 이해할 수 있다.
  3. 어떤 내용을 저장해야 하는지 이해할 수 있다.
   - 비즈니스 로직을 API 뒤에 감췄기 때문에 서비스 계층의 코드를 자유롭게 리팩터링 가능
   - 저장소 패턴 및 가짜 저장소(Fake Repository)와 조합하면 높은 수준의 테스트를 작성할 수 있다.
  
  ==> 단점
  1. 서비스 계층 또한 다른 추상화 계층에 불과
  2. 서비스 계층에 너무 많은 기능을 넣으면 빈약한 도메인 모델(Anemic Domain Model)과 같은 안티 패턴이 생길 수 있다.

06. 저장소 (Repository)

• 저장소 계층 ?
  ==> 데이터 엑세스 계층(Data Access Layer)이라고도 불리며 대표적으로 Database와 관련된 작업을 수행하는 계층
  • 모든 데이터가 Memory상에 존재하는 것처럼 가정 데이터 접근과 관련된 세부 사항을 감춘다.
  • 대표적인 저장소 계층의 메소드
     - add() : 새 원소를 저장소에 추가
     - get() : 이전에 추가한 원소를 저장소에서 가져온다.
  • 데이터를 저장하는 방법을 더 쉽게 변경, 테스트 코드 작성시 가짜 저장소를 제공하기가 더 쉬워진다.
  • 다른 계층에서는 저장소의 세부 사항이 어떤 방식으로 구현되어 있더라도 영향을 받지 않는다.
    ==> 객체 지향의 개념 중에서 추상화(Abstraction)와 관계가 있다.
  • 저장소 계층은 데이터 저장소를 간단히 추상화한 것으로 이 패턴을 사용하면 모델 계층과 데이터 계층을 분리할 수 있다.
• 저장소 계층의 장단점
  ==> 장점
  1. 모델과 인프라에 대한 사항을 완전히 분리했기 떄문에 단위 테스트(Unit test)를 위한 가짜 저장소를 쉽게 만들 수 있다.
  2. 도메인 모델을 미리 작성하면 처리해야 할 비즈니스 문제에 더 잘 집중할 수 있다.
  3. 접근 방식을 바꾸고 싶을 때 외래키나 마이그레이션 등을 염려하지 않고 모델에 반영할 수 있다.
  4. 객체를 테이블에 매핑하는 과정을 원하는 대로 제어할 수 있다. DB Schema를 단순화할 수 있다.
  5. 저장소 계층에 ORM을 사용할면 필요할 때 MySQL과 MySQL과 Postgres와 같이 DB를 서로 바꾸기 쉽다.
  
  ==> 단점
  1. 저장소 계층이 없더라도 ORM이 어느 정도 (모델과 저장소의) 결합을 완화시켜준다.
  2. ORM 매핑을 수동으로 하려면 개발 코스트가 더욱 소모된다.