도메인

도메인

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

예시

• 구현해야 할 소프트웨어의 대상
• 한 도메인은 하위 도메인으로 세분화 가능
  메인 도메인 : 쇼핑몰
  하위 도메인 : 주문, 회원, 혜택, 결제 등등 하위 도메인은 다른하위 도메인과 연동하여 완전한 기능을 제공
  ex) 고객 -> 주문 -> 결제 -> 배송
  
  

도메인 모델

특정 도메인을 개념적으로 정리한 모델
식별자를 부여해 대상을 쉽게 공유할 수 있도록 함
움직이는 방식에 대한 모델을 설계하기 때문에, 움직임을 예측할 수 있음

도메인 모델링 종류

1. 엔티티
   실제 DB 테이블과 연관되어 있는 핵심 클래스

• 엔티티를 기준으로 테이블이 생성되고 DB 스키마가 변경됨
  • 요청(Request)이나 응답(Response)을 전달하는 클래스로 사용하면 안 됨
• 엔티티 내부의 속성이 변경되더라도 여전히 동일한 엔티티
• 어떤 요소가 엔티티를 유일하게 식별하는지 정의하는 것도 중요
• 보통 이름이나 참조 번호를 사용

2. 아키텍처 패턴
3. 도메인 서비스

아키텍처 패턴

아키텍처 패턴

• 소프트웨어의 구조를 구성하기 위한 가장 기본적인 토대
• 각각의 시스템들과 그 역할이 정의되어 있고, 여러 시스템 사이의 관계와 규칙 등이 포함됨
• 검증된 구조로 개발을 진행하므로 안정적 개발 가능
• 아키텍처 패턴을 도입할 경우 도메인이 복잡할수록 모델이나 코드를 더 쉽게 변경할 수 있음

대표적 패턴

1. 저장소 패턴
   • 영속적인 저장소에 대한 추상화
2. 서비스 계층 패턴
   • 유스 케이스의 시작과 끝을 명확하기 정의
3. 작업 단위 패턴
   • 원자적 연산 제공
4. 애그리게이트 패턴
   • 데이터 정합성 강화 패턴

도입 전 고민할 내용

1. 아키텍처 패턴이 주는 이익과 비용에 대한 확실한 이유가 있어야 함
2. 해당하는 아키텍처 패턴을 채택했을 때, 어떤 장단점이 존재하는지 명확하게 인지해야 함
3. 여러 계층을 추가하기 위해 들이는 노력과 시간을 투자할 만한 가치가 있을 정도로 어플리케이션과 도메인이 복잡해야 함

계층형 아키텍처 패턴

계층형 아키텍처 패턴

계층을 분리해서 관리하는 패턴
현재 가장 흔하게 사용되고 있음

단순하고 대중적이면서 비용도 적게 드는 사실상의 표준 아키텍처
어떤 경우든 계층을 분리해서 유지하고, 각 계층이 자신의 바로 아래 계층에만 의존하게 만드는 것이 목표

계층화의 핵심은 각 계층은 응집도가 높고, 다른 계층과는 낮은 결합도를 가지게 하는 것
상위 계층은 하위 계층을 사용할 수 있지만 하위 계층은 상위 계층에 누가 있는지도 알 수 없고 사용도 할 수 없어야 함

일반적으로, 규모가 작은 어플리케이션은 3개, 크고 복잡한 경우 그 이상으로 계층을 나눔

3계층 아키텍처 구성

• 프레젠테이션 계층
• 비즈니스 로직 계층
• 데이터 액세스 계층

계층형 아키텍처 패턴의 장점

• 관심사를 분리하여 현재 구현하려는 코드를 명확하게 인지할 수 있음
• 계층별 의존성이 낮아 모듈 교체 시에도 수정이 용이
• 계층별 단위 테스트를 작성할 수 있어 테스트 코드 작성이 용이

3계층 아키텍처

구성

1. Controller : 어플리케이션 가장 바깥 부분으로, 요청/응답 처리
   • 클라이언트의 요청을 처리한 후 서버에서 처리된 결과 반환
2. Service : 어플리케이션 중간 부분. 실제 중요 작동이 많이 일어남
   • 아키텍처의 가장 핵심적인 비즈니스 로직이 수행되는 부분
3. Repository : 어플리케이션의 가장 안쪽 부분. DB와 맞닿아있음
   • 실제 데이터베이스의 데이터를 사용

수행 로직

1. 클라이언트가 요청을 보냄
2. 요청을 URL에 알맞는 컨트롤러가 수신함
3. 컨트롤러는 요청을 처리하기 위해 서비스를 호출
4. 서비스는 필요한 데이터를 가져오기 위해 저장소에게 데이터를 요청
5. 서비스는 저장소에서 가져온 데이터를 가공하여 컨트롤러에게 넘김
6. 컨트롤러는 서비스의 결과물을 클라이언트에게 전달

컨트롤러

컨트롤러

클라이언트의 요청을 수신
요청에 들어온 데이터 및 내용 검증
서버에서 수행된 결과를 클라이언트에 반환

프레젠테이션 계층

3계층 아키텍처 패턴에서 프레젠테이션 계층은 대표적으로 컨트롤러를 사용
하위 계층(서비스 계층, 저장소 계층)에서 발생하는 예외 처리
클라이언트가 전달한 데이터에 대해 유효성을 검증
클라이언트의 요청을 처리한 후 서버에서 처리된 결과 반환

서비스

서비스 계층

비즈니스 로직 계층이라고도 하며, 비즈니스 로직을 수행하여 실제 사용자의 요구사항을 반영하여 원하는 결과를 반환해주는 계층
프레젠테이션 계층과 데이터 액세스 계층 사이의 중간 다리 역할을 하여 서로 다른 두 계층이 직접 통신하지 않도록 함
서비스는 데이터가 필요할 때 저장소에게 데이터 요청
어플리케이션의 규모가 커질수록 서비스의 역할 및 코드도 점점 커짐

서비스 계층의 장단점

장점

1. 각각의 유스케이스와 워크플로우를 명확히 정의할 때 도움이 됨
   • 저장소에게 얻을 필요가 있는 데이터가 무엇인지 이해
   • 어떤 사전 검사와 현재 상태 검증을 필수적으로 해야하는지 이해
   • 어떤 내용을 저장해야 하는지 이해
2. 비즈니스 로직을 API 뒤에 감추어 서비스 계층의 코드를 자유롭게 리팩토링 가능
3. 저장소 패턴 및 가짜 저장소와 조합하면 높은 수준의 테스트 작성 가능

단점

1. 서비스 계층 또한 추상화 계층에 불과함
2. 서비스 계층에 너무 많은 기능을 넣으면 빈약한 도메인 모델(Anemic Domain Model) 같은 안티 패턴이 생길 수 있음

저장소

저장소

데이터 액세스 계층이라고 불리며, DB와 관련된 작업 수행
모든 데이터가 메모리상에 존재하는 것처럼 가정해 데이터 접근과 관련된 세부 사항을 감춤

대표적 저장소 계층 메소드

• add() : 새 원소를 저장소에 추가
• get() : 이전에 추가한 원소를 저장소에서 가져옴

저장소 계층을 구현했을 때, 데이터 저장 방법을 더 쉽게 변경이 가능하고, 테스트 코드 작성 시 가짜 저장소 제공이 쉬움

어플리케이션의 다른 계층은 저장소의 세부 사항이 어떤 방식으로 구현되든 영향을 받지 않음
-> 객체 지향의 개념 중, 추상화와 관계가 있음

저장소 계층은 데이터 저장소를 간단히 추상화한 것으로, 이 패턴을 사용하면 모델 계층과 데이터 계층을 분리 가능

저장소 계층의 장단점

장점

1. 모델과 인프라에 대한 사항을 완전히 분리했기 때문에 단위 테스트를 위한 가짜 저장소를 쉽게 만들 수 있음
2. 도메인 모델을 미리 작성하면 처리해야 할 비즈니스 문제에 더 잘 집중할 수 있음
3. 접근 방식을 바꾸고 싶을 때 외래키나 마이그레이션 등을 염려하지 않고 모델에 반영 가능
4. 객체를 테이블에 매핑하는 과정을 원하는 대로 제어할 수 있어 DB 스키마를 단순화할 수 있음
5. 저장소 계층에 ORM을 사용하면 DB를 바꾸기 쉬움

단점

1. 저장소 계층이 없더라도 ORM이 어느정도 (모델과 저장소의) 결합을 완화시킴
2. OTM 매핑을 수동으로 하려면 개발 코스트가 더 소모됨
   (Sequelize 같은 라이브러리를 말함)