[DDD] 3. 도메인 주도 설계 기본 요소

목차

1. 전술적 설계 - ENTITY와 VALUE OBJECT

2. 전술적 설계 - AGGREGATE와 REPOSITORY

3. 전술적 설계 - SERVICE

 

 

 

 

 

1. 전술적 설계 - ENTITY와 VALUE OBJECT

도출한 도메인 모델은 Entity와 Value Object로 구현될 수 있다.

 

1) Entity

• 식별자를 갖는다.
  
  • 객체의 상태 중 해당 객체의 고유한 성질을 표현할 수 있는 상태들을 식별자라고 부른다.
• 식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다.

식별자 생성

• 특정 규칙에 따라 생성
• UUID 사용
• 값을 직접 입력
• 일련번호 사용(시퀀스나 DB의 자동 증가 칼럼 사용)

도메인 모델에 set 메서드 넣지 않기

changeShippingInfo() vs setShippingInfo()
completePayment() vs setOrderState()

• 도메인 모델에 getter 메서드와 setter 메서드를 무조건 추가하는 것은 좋지 않은 버릇
• 특히 setter 메서드는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 한다.
• setter 메서드의 또 다른 문제는 도메인 객체를 생성할 때 완전한 상태가 아닐 수도 있다는 것이다.
• 도메인 객체가 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해 주어야 한다.

 

2) Value Object

의미를 명확하게 표현하거나 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용

예) 우편번호를 String으로 표현하는 것이 가능할까?

      String으로 저장은 가능하지만 실제로 여러 특수문자가 저장될 수 있다.

      우편번호 값 객체를 통해 유효성 검사를 할 수 있다.

• 시스템이 성숙함에 따라 데이터 값을 객체로 대체
• 밸류 타입은 불변
• 밸류 객체의 값을 변경하는 방법은 새로운 밸류 객체를 할당하는 것뿐이다.
• 항상 equals와 hashCode를 재정의 한다.

 

원시값으로 표현

class Car {
    private String name;
    private int position;
    
    Car(final String name, final int position) {
        if (Objects.isNull(name) || name.length() > 5) {
            throw new IllegalArgumentException();
        }
        this.name = name;
        this.position = position;
    }
}

 

Value Object로 표현

class CarName {
    private final value;
    
    CarName(final String value) {
        if (Objects.isNull(value) || value.length() > 5) {
            throw new IllegalArgumentException();
        }
        this.value = value;
    }
}

class Car {
    private CarName name;
    private int position;
    
    Car(final String name, final int position) {
        this.name = new CarName(name);
        this.position = position;
    }
    
    void changeName(final String name) {
        this.name = new CarName(name);
    }
}

 

불변 객체

• 모든 클래스를 상태를 변경할 수 없는 불변 클래스(immutable class)로 만들면 유지 보수성이 크게 향상된다.
• 불변 객체에는 아래의 ‘식별자 변경(identity mutability)’ 문제가 발생하지 않는다.
• 객체가 완전하고 견고한 상태이거나 아니면 아예 실패하는 실패 원자성(failure atomicity)을 가진다.
• 시간적 결합(temporal coupling)을 없앨 수 있다.
• 스레드 안정성
  • 객체가 여러 스레드에서 동시에(concurrently) 사용될 수 있고 예측 가능한(predictable) 결과를 보장하는 객체의 품질
• 단순성(simplicity), 객체가 더 단순해질 수록 응집도는 더 높아지고, 유지보수는 더 쉬워진다.
• 불변 객체의 크기가 작은 이유는 불변 객체의 경우 생성자 안에서만 상태를 초기화할 수 있기 때문이다.

 

---

2. 전술적 설계 - AGGREGATE와 REPOSITORY

Aggregate

Bounded Context 내에서 Entity와 Value Object를 묶는 개념

• 관련 객체를 하나로 묶은 군집
• 애그리거트는 군집에 속한 객체들을 관리하는 루트 엔티티를 갖는다.
• 애그리거트로 묶어서 바라보면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다.
• 애그리거트에 속한 객체는 유사하거나 동일한 라이프사이클을 갖는다.
• 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
• 두 개 이상의 엔티티로 구성되는 애그리거트는 드물게 존재한다.

 

AGGREGATE ROOT

다른 애그리거트와의 소통은 애그리거트 루트간에 메시지를 주고 받으며 이루어진다.

애그리거트 루트는 글로벌 ID를 가지고 애그리거트를 식별하는데 사용된다.

• 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다.
• 애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다.
• 이는 애그리거트의 내부 구현을 숨겨서 애그리거트 단위로 구현을 캡슐화할 수 있도록 돕는다.
• 루트 엔티티는 애그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공한다.

 

AGGREGATE 참조

• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
• ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다,
• ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 원천적으로 방지할 수 있다.

 

REPOSITORY

• 엔티티나 밸류가 요구사항에서 도출되는 도메인 모델이라면 리포지터리는 구현을 위한 도메인 모델
• 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의한다.
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공해야 한다.
• 리포지터리가 완전한 애그리거트를 제공하지 않으면, 필드나 값이 올바르지 않아 애그리거트의 기능을 실행하는 - 도중에 NullPointerException과 같은 문제가 발생하게 된다.
• 리포지토리는 애그리거트(루트) 단위로 존재하며 테이블 단위로 존재하는 것이 아니다.

 

---

3. 전술적 설계 - SERVICE

상품, 주문, 할인 쿠폰, 회원과 같이 여러 애그리거트를 활용해 결제 금액을 계산하는 로직은 어떤 애그리거트에 위치해야 할까?

 

도메인 서비스

한 애그리거트에 넣기 애매한 도메인 개념을 구현하려면 애그리거트에 억지로 넣기보다는 도메인 서비스를 이용해서 도메인 개념을 명시적으로 드러내면 된다.

• 응용 영역의 서비스가 용용 로직을 다룬다면 도메인 서비스는 도메인 로직을 다룬다.
• 도메인 영역의 애그리거트나 밸류와 같은 다른 구성요소와 비교할 때 다른 점은 상태 없이 로직만 구현한다.
• 서비스를 사용하는 주체는 애그리거트가 될 수도 있고 응용 서비스가 될 수도 있다.
• 애그리거트 메서드를 실행할 때 도메인 서비스를 인자로 전달하지 않고 반대로 도메인 서비스의 기능을 실행할 때 애그리거트를 전달하기도 한다.
• 특정 기능이 응용 서비스인지 도메인 서비스인지 감을 잡기 어려울 때는 해당 로직이 애그리거트의 상태를 변경하거나 애그리거트의 상태 값을 계산하는지 검사해 보면 된다.

 

FACTORY

• 어떤 객체를 생성하는 일이 복잡하다면 FACTORY를 이용해 이것을 캡슐화할 수 있다.
• 생성자, 팩토리 클래스
• 연관된 애그리거트에서 생성할 수 있다.
• 어떤 다른 곳에서 해당 객체를 생성할 때 생산자의 정보를 필요로 하는 것을 줄일 수 있다.
• 아울러 생산자와 생성된 객체 사이의 특별한 관계를 전해주기도 합니다.

 

 

 

 

 

 

 

 

 

출처

NEXTSTEP: DDD 세레나데 3기