용어정리
- 도메인
- 세상의 어떤것
- 현실의 문제점을 해결하기 위한 문제들
- 모델
- 대상 도메인의 내부적인 표현(설계, 개발 등에 활용)
- 유비쿼터스 언어
- 분야와 상관없이 전반적으로 활용될 공통된 언어
- 집합
- 데이터를 변경할 때 하나의 단위로 간주되는 관련된 객체들의 집합(root)
왜?
- DDD가 왜필요한지 알기위해
(책리뷰) 도메인 주도 설계란 무엇인가?
서문
- 도메인 주도 설계를 하면, 기술 변화가 일어나도, 도메인의 변경점은 없다.
- DDD를 널리 알리고싶었다
1. 도메인 주도 설계란 무엇인가?
- 현실의 문제들을 푼다 → 도메인 → 모델 설계 과정이 필요
- 도메인 = 세상의 어떤것
- 모델 = 대상 도메인의 내부적인 표현(설계, 개발에 필수)
- 소프트웨어 개발자와 <> 도메인 전문가와의 소통시 유용하다. 설계시 에자일 방식으로 하는것 매우 중요
- 전통적 탑다운 방식의 개발(요청문제파악 > 모델 설계 > 개발)에서 에자일 방식(모두가 참여하여 모델 정의)로 변경시 설계단계에서 완벽하지 못한 문제점들 조기의 발견 및 수정 완성할수있는 장점
- 모델링에서는 명사와 동사를 구분하여, 각각 클래스와 메서드
2. 유비쿼터스 언어
- 도메인 전문가 <> 개발자 사이의 공통된 언어가 필요하다
- 각자 전문 언어가 다름.
- 개발자는 각자
- 모델 구성도만을 그려서 소통필요
- UML과같은경우, 소규모로 각 모델에 따른 구성도 표기 선호
- UML은 간단한 모델 구성도보다 훨씬 복잡도 높음
- 모델 구성 및 UML 작성시, 속성으로 표현되지않는 목적성, 의도, 이슈는 문서로 작성
- 문서 작성시 최대한 간단하도록해야함. 유지 보수성 높여야함. 명료함 필수
- 클래스의 행동 및 제약사항도 표기
- 개발자의 역할은 모델→클래스 관계 → 코드화
3. 모델 주도 설계
모델주도 설계를 위한 블록
- DDD 관점에서 객체 모델링 및 소프트웨어 설계의 핵심 요소
계층형 아키텍처
- 사용자 인터페이스: 사용자에게 정보를 보여주고, 사용자의 명령을 해석
- 애플리케이션 레이어: 애플리케이션 활동을 조율하는 얇은 레이어. 업무 로직을 포함하지않는다. 비즈니스 객체의 상태는 보관X 단, 애플리케이션 작업의 처리 상태 보관O
- 도메인 레이어: 도메인 정보를 포함한다. 도메인 정보를 포함한다.
- 비즈니스 객체와 이 객체의 상태 정보 중 가능한 부분의 영속성에 대한 책임은 인프라스트럭처 레이어로 위임된다.
- 인프라스트럭처 레이어: 다른 레이어 모두를 지원하는 라이브러리로 동작한다.
엔티티
- 식별성(유일한ID)
- 속성 값이 모두 동일하더라도, 구별가능
값 객체
- 속성 값이 동일하면, 동일한 객체
- 도메인 객체의 속성들을 담고
- 값 객체를 공유할수있다면, 변경 불가능하도록 만든다.
서비스
- 서비스의 특징 3가지
- 객체의 행위, 모델의 행위(서비스에 의해 수행되는 오퍼레이션)은 일반적으로 엔티티 또는 값 객체에 속할 수없는 도메인의 개념을 나타낸다
- 수행되는 오퍼레이션은 도메인의 다른 객체를 참조한다
- 오퍼레이션은 상태를 저장하지않는다(stateless)
- 유비쿼터스 언어의 일부로 사용하여 이름 정의
모듈
- 모델 전체에서 관련된 개념과 작업을 조직화함
- 낮은 결합도, 높은 응집도
집합
- 도메인 객체의 생명주기 다루는 전략1
- 일대다 이상의 관계에서 다양한 연관된 객체를 활용해야할 때, root 엔티티를 활용
- 양방향을 단반향으로 복잡도를 줄이는 것도 방법
- 모델의 핵심 사항이 아닌 관계있다면 관계 제거
- root활용(내부 집합된 다른 객체의 참조를 갖는 대상)
- 외부에서는 내부 집합 객체 접근시 root를 통해서만 접근
- root 삭제시 관련 내부 객체 모두 제거됨
- 내부 객체 값 필요시 값 복사를 통한 정보 제공
팩토리
- 도메인 객체의 생명주기 다루는 전략2
- 한 도메인에만 속하지 않은 연관된 객체들을 만들어야할때, 팩토리를 사용
- 불변식적용
- 새로운 객체 생성에만 관여(기존객체 로드X)
레포지토리
- 도메인 객체의 생명주기 다루는 전략3
- 인프라 및 DB와 다른 계층간의 분리
- 객체의 캐싱 또는 존재했던(DB영구) 객체 가져오는 역할
4. 깊은 통찰을 향한 리팩터링
리팩터링은 작게는 메서드부터 크게는 구조 전체이며, 충분한 핵심 도메인 설계를 통해 비용을 줄일 수 있다
도메인 설계시 초반에는 암시적 개념에서 유비쿼터스 언어로 변환하여, 일부는 핵심 명시적 개념으로 남는다. 나머지는 암시적 개념으로 존재한다.
설계가 잘못되었다면, 비효율이 발생하고, 이때 암시적 개념들을 명시적개념들로 바꾸는 작업들이 필요할수있다.
명시적을 만들어낼때 3가지 도구
제약 조건
- 객체 데이터는 불변식 로직을 지켜야하며, 해당 로직은 메시드로 정의하여, 리팩토리가능하다
처리
- 프로세스를 구현하는 최고의 방법은 서비스를 이용하는것이다.
- 적합한 객체를 선택하여 해당 행위를 추가
- 여러 방법 가능하다면, 전략패턴을 통해 한 객체의 알고리즘으로 캡슐화 표현가능
명세
- 객체가 특정 기준을 만족하는지 여부를 확인하는 목적으로 활용
1
2
3
4
5
6
7
8
9
10
11Customer customer =
customerRepository.findCustomer (customerIdentiy);
...
Specification customerEligibleForRefund = new Specification(
new CustomerPaidHisDebtsInThePast (),
new CustomerHasNoOutstandingBalances ());
if (customerEligibleForRefund.isSatisfiedBy (customer)
{
refundService.issueRefundTo (customer);
｝