Domain Driven Design으로써 소프트웨어를 설계하는 하나의 방법으로 볼 수 있다.

도메인을 중심에 놓고 도메인 모델 설계에 집중하는 방식이다.

• 간략 용어설명

  • Context: 해당 도메인의 의미를 결정하는 단어, 문장을 나타냄
  • Domain: 지식의 영역, 활동, 물체, 영향 등을 의미함. 소프트웨어로 해결하고자 하는 문제 영역
  • Model: 도메인을 설명하고 해당 도메인과 관련된 문제를 해결하는데 사용할 추상화
  • Ubiquitous Language: 모델을 중심으로 구성된 언어. 모든 팀 구성원이 사용

• 도메인 아키텍처

1. 표현 영역 ( Web에서는 Http 프로토콜 )
   1. 어플리케이션에서 요청을 응용 영역이 필요로 하는 형식으로 변환 후 전달
   2. 응용 영역의 응답을 표현 영역이 이해 가능한 형태로 변환 후 전달
2. 응용 영역 ( Application Service )
   1. 시스템이 사용자에게 제공해야 할 기능을 구현
   2. 도메인 영역의 모델을 이용한다.
3. 도메인 영역 ( Domain, Domain Service )
   1. 도메인 모델, 리포지토리, 도메인 서비스가 구현되어 있음
   2. 핵심 로직을 이곳에서 구현한다.
4. 인프라스트럭처
   1. 실제 저장소에 관한 구현 기술을 다룬다.
   2. RDBMS, MQ, No-Sql DB 와 같은 미들웨어와의 연결이 중점이다.

• 표현 영역

  • 사용자의 요청을 해석하고 응용 영역의 서비스를 호출하는 영역
  • 사용자의 요청에 대한 응답을 프로토콜이 이해할 수 있는 형태로 변형하는 역할을 담당.
  • 사용자의 세션 관리
  • 화면의 흐름을 제공하고 제어
  • 필수 값, 값의 형식, 범위 등을 검증
  • 유저의 인증 검사

• 응용 영역

  • 실제 사용자가 원하는 기능을 제공하는 영역
  • 주로 도메인 객체 간의 흐름을 제어
  • 트랙잭션 처리를 담당
  • 중복되는 기능은 별도 클래스(Helper)를 이용하여 처리함
  • 도메인 이벤트의 처리 및 발생 담당
  • 데이터의 존재 유무와 같은 논리적 오류에 대한 검증
  • 유저의 인가 검사

• 도메인 모델

  • 특정 도메인을 개념적으로 표현 한 것.
  • 도메인을 이해하기 위한 개념
  • 특정 도메인을 한정적으로 구분짓기 위해 사용함.
  • 도출한 모델은 엔티티(Entity)와 벨류(Value)로 구분 할 수 있다.
  • Set Method를 사용하지 않고 의미를 부여한 함수를 통해 값을 변경한다.
  • 도메인에 직접 서비스를 주입하지 않도록 주의해라.

1. 엔티티
   1. 거의 모든 경우에 식별자(유니크 ID) 를 가진다.
   2. 후에 기술한 애그리거트 루트일 가능성이 높다.
   3. 도메인의 기능을 제공한다. ( JPA의 엔티티와는 다르다! )
2. 밸류
   1. 개념적으로 완전한 하나를 표현 할 때 사용한다. ( ex: 주소 = 시 + 군/구 + 상세 주소 )
   2. 일반적으로 데이터 변경 기능을 제공하지 않는다. ( 불변 객체 )