📖 도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지

2023-01-09

도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지 책을 읽고 내용을 아주 간단하게 정리한 글입니다. 책에는 자세한 설명과 예제가 많으니 꼭 구입해서 읽는것을 추천합니다~👍

1. 도메인 모델 시작하기

1.1 도메인이란?

소프트웨어로 해결하고자 하는 문제 영역을 도메인이라 한다.

1.2 도메인 전문가와 개발자 간 지식공유

전문가나 관련자가 요구한 내용이 항상 올바른 것은 아니다. 그래서 개발자는 요구사항을 이해할 때 왜 이런 기능을 요구하는지 또는 실제로 원하는게 무엇인지 생각하고 전문가와 대화를 통해 진짜로 원하는 것을 찾아야 한다.

1.3 도메인 모델

도메인 모델은 특정 도메인을 개념적으로 표현한 것이다. 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는데 도움이 된다. 도메인 모델을 이해하는 데 도움이 된다면 객체기반 표현이든, 함수 표현이든 표현 방식이 무엇인지는 중요하지 않다.

1.4 도메인 모델 패턴

영역	설명
사용자 인터페이스(UI) 또는 표현(Presentation)	사용자의 요청을 처리하고 사용자에게 정보를 보여준다. 여기서 사용자는 소프트웨어를 사용하는 사람뿐만 아니라 외부 시스템일 수도 있다.
응용(Application)	사용자가 요청한 기능을 실행한다. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다.
도메인(Domain)	시스템이 제공할 도메인 규칙을 구현한다.
인프라스트럭처(Infrastructure)	데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리한다.

개념 모델과 구현 모델
개념 모델은 순수하게 문제를 분석한 결과물이다. 개념 모델은 데이터베이스, 트랜잭션 처리, 성능, 구현 기술과 같은 것을 고려하고 있지 않기 때문에 실제 코드를 작성할 때 개념 모델을 있는 그대로 사용할 수 없다. 그래서 개념 모델을 구현 가능한 형태의 모델로 전환하는 과정을 거치게 된다.

처음부터 완벽한 개념 모델을 만들기보다는 전반적인 개요를 알 수 있는 수준으로 개념 모델을 작성해야한다. 프로젝트 초기에는 개요 수준의 개념 모델로 도메인에 대한 전체 윤곽을 이해하는 데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜 나가야 한다.

1.5 도메인 모델 도출

도메인을 모델링할 때 기본이 되는 작업은 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것이다. 이 과정은 요구사항에서 출발한다. 요구사항을 통해 도메인 모델을 점진적으로 만들어 나간다. 이렇게 만든 모델은 요구사항 정련을 위해 도메인 전문가나 다른 개발자와 논의하는 과정에서 공유되기도 한다. 모델을 공유할 때는 화이트보드나 위키 같은 도구를 사용해서 누구나 쉽게 접근할 수 있도록 하면 좋다.

1.6 엔티티와 벨류

1.6.1 엔티티

식별자를 가진다.
식별자는 엔티티 객체마다 고유하다.

1.6.2 엔티티의 식별자 생성

특정 규칙에 따라 생성.
UUID나 Nano ID와 같은 고유 식별자 생성기 사용.
값을 직접 입력.
일련번호 사용(시퀀스나 DB의 자동 증가 컬럼 사용).

1.6.3 밸류 타입

밸류 타입은 개념적으로 완전한 하나를 표현할 때 사용한다.
의미를 명확하게 표현하기 위해 사용되기도 한다.
밸류 타입을 위한 기능을 추가할 수 있다.
불변으로 구현한다.

1.6.4 엔티티 식별자와 밸류 타입

식별자를 위한 밸류 타입을 사용해서 의미가 잘 드러나도록 할 수 있다.

1.6.5 도메인 모델에 set 넣지 않기

상태 변경을 위한 set 사용시 도메인 지식이 코드에서 사라진다.
객체를 생성할 때 온전하지 않은 상태가 될 수 있다.

DTO도 최대한 불변 객체로 사용하도록 하자

1.7 도메인 용어와 유비쿼터스 언어

도메인 용어
STEP1, STEP2 같은것이 아닌 PAYMENT_WAITING, PREPARING 같은 도메인 용어를 사용하여 코드를 작성한다.

유비쿼터스 언어
전문가, 관계자 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드 테스트 등 모든 곳에서 같은 용어를 사용한다. 이렇게 하면 소통 과정에서 발생하는 용어의 모호함을 줄일 수 있고 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있다.

2. 아키택처 개요

2.1 네 개의 영역

표현 영역
사용자의 요청을 받아 응용 영역에 전달하고 응용 영역의 처리 결과를 다시 사용자에게 보여주는 역할

응용 영역
표현 영역을 통해 요청을 전달받아 시스템이 사용자에게 제공해야 할 기능을 구현하는 역할. 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임한다.

도메인 영역
도메인 모델을 구현. 도메인 모델은 도메인의 핵심 로직을 구현한다.

인프라스트럭처 영역
구현 기술에 대한 것을 다룬다. 이 영역은 논리적인 개념을 표현하기보다는 실제 구현을 다룬다.

2.2 계층 구조 아키텍처

상위 계층에서 하위 계층으로 의존만 존재하고 하위 계층에서 상위 계층에 의존하지 않는다.

2.3 DIP

DIP(Dependency Inversion Principle) 의존성 역전 원칙

2.4 도메인 영역의 주요 구성요소

요소	설명
엔티티 ENTITY	고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖는다. 주문, 회원, 상품과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다.
밸류 VALUE	고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나인 값을 표현한다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 밸류 타입의 속성으로도 사용할 수 있다.
애그리거트 AGGREGATE	연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 예를 들어 주문과 관련된 Order 엔티티, OrderLine 밸류, Orderer 밸류 객체를 ‘주문’ 애그리거트로 묶을 수 있다.
리포지터리 REPOSITORY	도메인 모델의 영속성을 처리한다. 예를 들어 DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능을 제공한다.
도메인 서비스 DOMAIN SERVICE	특정 엔티티에 속하지 않은 도메인 로직을 제공한다. 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.

2.5 요청 처리 흐름

2.6 인프라스트럭처 개요

도메인 객체의 영속성 처리, 트랜젝션, REST 클라이언트 등 다른영역에서 필요로 하는 프레임워크, 구현 기술, 보조 기능을 지원한다.
보통 의존성역전 사용
@Transactional 같은 DIP를 사용하지 않는 예외도 편의를 위해 허용

2.7 모듈 구성

3. 애그리거트

3.1 애그리거트

복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만드려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요한데, 그 방법이 바로 애그리거트다. 애그리거트는 관련된 객체를 하나의 군으로 묶어 준다.

애그리거트는 경계를 갖는다. 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다. 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다. 경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다. 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.

3.2 애그리거트 루트

애그리거트에 속한 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데, 이 책임을 지는 것이 바로 애그리거트 루트 엔티티이다. 애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접 또는 간접적으로 속하게 된다.

3.2.1 도메인 규칙과 일관성

애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다. 이를 위해 애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다.
애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안된다. 이것은 모델의 일관성을 깨는 원인이 된다.
단순히 필드를 변경하는 set 메서드를 공개(public) 범위로 만들지 않는다.
밸류 타입은 불변으로 구현한다.

3.2.2 애그리거트 루트의 기능 구현

애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해 기능을 완성한다.
애그리거트 루트가 구성요소의 상태만 참조하는 것은 아니다. 기능 실행을 위임하기도 한다.

3.2.3 트랜젝션 범위

작을수록 좋다
한 트랜젝션에서는 한 개의 애그리거트만 수정한다.
부득이하게 한 트랜젝션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 수정하지 말고, 응용 서비스에서 애그리거트를 수정하도록 구현한다.
두 개 이상의 애그리거트를 수정해야 한다면, 도메인 이벤트를 사용한다.

3.3 리포지터리와 애그리거트

애그리거트: 개념상 완전한 하나의 도메인 모델
리포지터리: 애그리거트 영속성을 처리
- save: 애그리거트 저장
- findById: ID로 애그리거트를 구함

3.4 ID를 이용한 애그리거트 참조

애그리거트도 다른 애그리거트를 참조한다.
애그리거트 참조는 애그리거트 루트가 다른 애그리거트 루트를 참조한다는 뜻이다.

필드 참조

필드 참조 문제점

편한 탐색 오용
결합도 증가
성능에 대한 고민
확장 어려움

ID를 이용한 참조

ID 참조 장점

모델의 복잡도를 낮춘다
응집도 증가
구현 난이도 감소
확장 용이

3.4.1 ID를 이용한 참조와 조회 성능

ID를 이용한 조회는 N + 1 문제가 발생한다.
해결방법은 아래와 같다.

조회 전용 쿼리를 만들어 사용한다.
쿼리가 복잡하거나 특화된 기능을 사용해야 한다면 마이바티스와 같은 기술로 구현하는걸 고려한다.

3.5 애그리거트 간 집합 연관

1-N, M-N 연관에 대해 살펴본다.

1-N

public class Category {
    private Set<Product> products; //다른 애그리거트에 대한 1-N 연관
}

조회시 개념적으로 애거리거트 간에 1-N 연관이 있더라도 성능 문제 때문에 실제 구현에 반영하지 않는다. N-1로 연관지어 구현한다.

public class Product {
    private CategoryId categoryId;
}

public class ProductListService {
    public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
        Category category = categoryRepository.findById(categoryId);
        checkCategory(category);
        List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
        int totalCount = productRepository.countByCategoryId(category.getId());
        return new Page(page, size, totalCount, products);
    }
}

M-N
M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다. 하지만 구현은 요구사항을 고려해서 결정한다. 개념적으로는 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 되는 것이다.

public class Product {
    private Set<CategoryId> categoryIds;
}

RDBMS에서 M-N 연관 구현

JPA를 이용하여 ID 참조를 이용한 M-N 단방향 연관 구현

@Entity
@Table(name = "product")
public class Product {
    @EmbeddedId
    private ProductId id;
    
    @ElementCollection
    @CollectionTable(name = "product_category",
        joinColumns = @JoinColumn(name = "product_id"))
    private Set<CategoryId> categoryIds;
    ...
}

3.6 애그리거트를 팩토리로 사용하기

애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것을 고려한다.
별도의 도메인 서비스나, 팩토리 클래스를 만들 수도 있다.

public class Store {

    public Product createProduct (ProductId newProductId, ...생략) {
        if (isBlocked()) {
            throw new StoreBlockedException();
        }
        return new Product(newProductId, getId(), ...생략);
    }

}

4. 리포지터리와 모델 구현

자세한 설명은 아래의 문서와 책을 읽는 것을 추천합니다. 👍

4.1 JPA를 이용한 리포지터리 구현

4.1.1 모듈 위치

4.1.2 리포지터리 기본 기능 구현

public interface OrderRepository {
    Order findById(OrderNo no);
    void save(Order order);
}

public class JpaOrderRepository implements OrderRepository {
    @PersistenceContext
    private EntityManager entityManager;

    @Override
    public Order findById(OrderNo id) {
        return entityManager.find(Order.class, id);
    }

    @Override
    public void save(Order order) {
        entityManager.persist(order);
    }
}

4.2 스프링 데이터 JPA를 이용한 리포지터리 구현

@Entity
@Table(name = "purchase_order")
@Access(AccessType.FIELD)
public class Order {
    @EmbeddedId
    private OrderNo number;

    @Version
    private long version;

    @Embedded
    private Orderer orderer;

    ...생략...
}

public interface OrderRepository extends Repository<Order, OrderNo> {
    Optional<Order> findById(OrderNo id);

    void save(Order order);

    default OrderNo nextOrderNo() {
        int randomNo = ThreadLocalRandom.current().nextInt(900000) + 100000;
        String number = String.format("%tY%<tm%<td%<tH-%d", new Date(), randomNo);
        return new OrderNo(number);
    }
}

@Service
public class CancelOrderService {
    private OrderRepository orderRepository;
    private CancelPolicy cancelPolicy;

    public CancelOrderService(OrderRepository orderRepository, CancelPolicy cancelPolicy) {
        this.orderRepository = orderRepository;
        this.cancelPolicy = cancelPolicy;
    }

    @Transactional
    public void cancel(OrderNo orderNo, Canceller canceller) {
        Order order = orderRepository.findById(orderNo)
                .orElseThrow(() -> new NoOrderException());
        if (!cancelPolicy.hasCancellationPermission(order, canceller)) {
            throw new NoCancellablePermission();
        }
        order.cancel();
    }
}

4.3 매핑 구현

4.3.1 엔티티와 밸류 기본 매핑 구현

애그리거트와 JPA 매핑을 위한 기본 규칙

애그리거트 루트는 엔티티이므로 @Entity로 매핑 설정한다.

한 테이블에 엔티티와 밸류 데이터가 같이 있다면

밸류는 @Embeddable로 매핑 설정한다.
밸류 타입 프로퍼티는 @Embedded로 매핑 설정한다.
매핑할 컬럼명 변경은 @AttributeOverrides 를 이용한다

@Embeddable
public class ShippingInfo {
    @Embedded
    @AttributeOverrides({
            @AttributeOverride(name = "zipCode", column = @Column(name = "shipping_zip_code")),
            @AttributeOverride(name = "address1", column = @Column(name = "shipping_addr1")),
            @AttributeOverride(name = "address2", column = @Column(name = "shipping_addr2"))
    })
    private Address address;
    @Column(name = "shipping_message")
    private String message;
    @Embedded
    private Receiver receiver;

@Entity
@Table(name = "purchase_order")
@Access(AccessType.FIELD)
public class Order {
    ...
    @Embedded
    private Orderer orderer;

    @Embedded
    private ShippingInfo shippingInfo;
    ...

4.3.2 기본 생성자

엔티티는 기본 생성자가 필요하다.

protected Receiver(){}

4.3.2 필드 접근 방식 사용

@Access를 이용해서 명시적으로 접근 방식을 지정하지 않으면 @Id나 @EmbeddedId의 위치에 따라 접근 방식을 결정한다.

@Entity
@Table(name = "purchase_order")
@Access(AccessType.FIELD)
public class Order {
    ...생략...
}

4.3.4 AttributeConverter를 이용한 밸류 매핑 처리

두 개 이상의 프로퍼티를 가진 밸류 타입을 한 개 컬럼에 매핑하려면 @Embeddable 애너테이션으로는 처리할 수 없다. 이럴 때 사용할 수 있는 것이 AttributeConverter이다.

@Converter(autoApply = true)
public class MoneyConverter implements AttributeConverter<Money, Integer> { 
    // Money는 밸류 타입, Integer는 DB 타입

    // 밸류 타입을 DB 칼럼 값으로 변환
    @Override
    public Integer convertToDatabaseColumn(Money money) {
        return money == null ? null : money.getValue();
    }

    // DB 칼럼 값을 밸류로 변환
    @Override
    public Money convertToEntityAttribute(Integer value) {
        return value == null ? null : new Money(value);
    }
}

// @Converter(autoApply = true) 작성한 타입에 대해 자동 적용
public class Order {

    @Column(name = "total_amounts")
    private Money totalAmounts;
}

// @Converter(autoApply = false) 기본값, 직접 지정해야함
public class Order {

    @Convert(converter = MoneyConverter.class)
    @Column(name = "total_amounts")
    private Money totalAmounts;
}

4.3.5 밸류 컬렉션: 별도 테이블 매핑

밸류 컬렉션을 별도 테이블로 매핑할때는 @ElementCollection과 @CollectionTable을 함께 사용한다.

@Entity
@Table(name = "purchase_order")
public class Order {
    @EmbeddedId
    private OrderNo number;

    @ElementCollection(fetch = FetchType.LAZY)
    @CollectionTable(name = "order_line", joinColumns = @JoinColumn(name = "order_number"))
    @OrderColumn(name = "line_idx")
    private List<OrderLine> orderLines;
    ...생략...
}

@Embeddable
public class OrderLine {
    @Embedded
    private ProductId productId;

    @Column(name = "price")
    private Money price;

    @Column(name = "quantity")
    private int quantity;

    @Column(name = "amounts")
    private Money amounts;
}

4.3.6 밸류 컬렉션: 한 개 컬럼 매핑

한 개 컬럼에 콤마로 구분해서 저장할 때 사용. AttributeConverter를 이용한다.

public class EmailSet {
    private Set<Email> emails = new HashSet<>();

    public EmailSet(Set<Email> emails) {
        this.emails.addAll(emails);
    }

    public Set<Email> getEmails() {
        return Collections.unmodifiableSet(emails);
    }
}

public class EmailSetConverter implements AttributeConverter<EmailSet, String> {
    @Override
    public String convertToDatabaseColumn(EmailSet attribute) {
        if (attribute == null) return null;
        return attribute.getEmails().stream()
                .map(email -> email.getAddress())
                .collect(Collectors.joining(","));
    }

    @Override
    public EmailSet convertToEntityAttribute(String dbData) {
        if (dbData == null) return null;
        String[] emails = dbData.split(",");
        Set<Email> emailSet = Arrays.stream(emails)
                .map(value -> new Email(value))
                .collect(toSet());
        return new EmailSet(emailSet);
    }
}

4.3.7 밸류를 이용한 ID 매핑

JPA에서 식별자 타입은 Serializable 타입이어야 하므로 Serializable 인터페이스를 상속받아야 한다. 밸류 타입으로 식별자를 구현할 때 얻을 수 있는 장점은 식별자에 기능을 추가할 수 있다는 점이다.

@Entity
@Table(name = "purchase_order")
public class Order {
    @EmbeddedId
    private OrderNo number;
    ...생략...
}

@Embeddable
public class OrderNo implements Serializable {
    @Column(name = "order_number")
    private String number;
    ...생략...
}

4.3.8 별도 테이블에 저장하는 밸류 매핑

루트 엔티티 외에 또 다른 엔티티가 있다면 진짜 엔티티인지 의심해 봐야한다. 단지 별도 테이블에 데이터를 저장 한다고 해서 엔티티인 것은 아니다.

예를 들어 게시글 데이터를 ARTICLE 테이블과 ARTICLE_CONTENT 테이블로 나눠서 저장한다고 하자.

엔티티로 매핑 예 (잘못 됨)

ARTICLE_CONTENT에 ID는 식별자이긴 하지만 이는 ARTICLE 테이블과 연결을 위함이지 ARTICLE_CONTENT를 위한 별도 식별자가 필요해서가 아니다.

별도 테이블로 매핑

ARTICLE_CONTENT을 밸류로 만들고 @Embeddable로 매핑한다.

@Entity
@Table(name = "article")
@SecondaryTable(
        name = "article_content",
        pkJoinColumns = @PrimaryKeyJoinColumn(name = "id")
)
public class Article {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;

    @AttributeOverrides({
            @AttributeOverride(
                    name = "content",
                    column = @Column(table = "article_content", name = "content")),
            @AttributeOverride(
                    name = "contentType",
                    column = @Column(table = "article_content", name = "content_type"))
    })
    @Embedded
    private ArticleContent content;
}

밸류 매핑을 별도 테이블로 저장 하려면 @SecondaryTable과 @AttributeOverride을 사용한다. 하지만 @SecondaryTable은 jpa.find("id");(조회)를 실행할 때 두 테이블을 조인해서 가져온다. 게시글 목록 같은 화면은 ARTICLE의 데이터만 필요하지 ARTICLE_CONTENT는 필요없다.

이를 해결하기 위해 ARTICLE_CONTENT을 엔티티로 매핑하고 ARTICLE에서 ARTICLE_CONTENT을 지연로딩 할 수도 있다. 하지만 이는 밸류 모델을 엔티티로 만드는 것이므로 좋은 방법은 아니다. 대신 조회 전용 기능을 사용하는 것이 좋다.

4.3.9 밸류 컬렉션을 @Entity로 매핑하기

@OneToMany 사용하여 연관관계를 맺는다.

@Entity
@Table(name = "product")
public class Product {
    ...생략...
    @OneToMany(cascade = {CascadeType.PERSIST, CascadeType.REMOVE},
            orphanRemoval = true, fetch = FetchType.LAZY)
    @JoinColumn(name = "product_id")
    @OrderColumn(name = "list_idx")
    private List<Image> images = new ArrayList<>();
    ...생략...

@Inheritance를 이용하여 엔티티 상속도 가능하다.

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "image_type")
@Table(name = "image")
public abstract class Image {
    ...생략...
}

@Entity
@DiscriminatorValue("II")
public class InternalImage extends Image {
    ...생략...
}
@Entity
@DiscriminatorValue("EI")
public class ExternalImage extends Image {
    ...생략...

4.3.10 ID 참조와 조인 테이블을 이용한 단방향 M-N 매핑

@Entity
@Table(name = "product")
public class Product {
    ...생략...
    @ElementCollection(fetch = FetchType.LAZY)
    @CollectionTable(name = "product_category",
            joinColumns = @JoinColumn(name = "product_id"))
    private Set<CategoryId> categoryIds;
    ...생략...
}

4.4 애그리거트 로딩 전략

// @Embeddable 컬렉션에 대한 즉시 로딩 설정
@ElementCollection(fetch = FetchType.EAGER)

// @Entity 컬렉션에 대한 지연 로딩 설정
@OneToMany(fetch = FetchType.LAZY)

즉시 로딩: 에그리거트 루트를 구할 때 연관된 구성 요소를 DB에서 함께 읽어온다.
지연 로딩: 실제 컬렉션에 접근할 때 DB에서 조회한다.

4.5 애그리거트 영속성 전파

애그리거트가 완전한 상태여야 한다는 것은 애그리거트 루트를 조회할 때뿐만 아니라 저장하고 삭제할 때도 하나로 처리해야 함을 의미한다.

저장 메서드는 애그리거트 루트만 저장하면 안되고 애그리거트에 속한 모든 객체를 저장해야 한다.
삭제 메서드는 애그리거트 루트뿌만 아니라 애그리거트에 속한 모든 객체를 삭제해야 한다.
@Embeddable 매핑 타입은 함께 저장되고 삭제 되므로 추가 설정이 필요없다.
@Entity 타입에 대한 매핑은 cascade 속성을 사용한다.

@OneToMany(cascade = {CascadeType.PERSIST, CascadeType.REMOVE})

4.6 식별자 생성 기능

식별자는 크게 세 가지 방식 중 하나로 생성한다.

사용자가 직접 생성
도메인 로직으로 생성
DB를 이용한 일련번호 사용

4.7 도메인 구현과 DIP

JPA의 @Entity나 @Table, extends Repository 인터페이스는 DIP 원칙을 어기고 있지만 개발 편의성과 실용성을 가지고, 복잡도를 높이지 않으면서 기술에 따른 구현 제약이 낮다면 합리적으로 선택하여 사용할 수 있다.

5. 스프링 데이터 JPA를 이용한 조회 기능

5.1 시작에 앞서

5.2 검색을 위한 스펙

조회를 위해 다양한 검색 조건을 조합해야 할 때가 있다. 이 때 사용할 수 있는 것이 스펙(Specification)이다.

5.3 스프링 데이터 JPA를 이용한 스펙 구현

스프링 데이터 JPA가 제공하는 Specification 인터페이스

public interface Specification<T> {
  Predicate toPredicate(Root<T> root, CriteriaQuery<?> query, CriteriaBuilder builder);
}

레포지토리 인터페이스 상속

public interface CustomerRepository extends CrudRepository<Customer, Long>, JpaSpecificationExecutor<Customer> {
    List<Customer> findAll(Specification<Customer> spec);
    List<Customer> findAll(Specification<Customer> spec, Sort sort);
    List<Customer> findAll(Specification<Customer> spec, Pageable pageable);
}

스펙 생성 기능을 별도 클래스로 구현

public class CustomerSpecs {

  public static Specification<Customer> isLongTermCustomer() {
    return (root, query, builder) -> {
      LocalDate date = LocalDate.now().minusYears(2);
      return builder.lessThan(root.get(Customer_.createdAt), date);
    };
  }

  public static Specification<Customer> hasSalesOfMoreThan(MonetaryAmount value) {
    return (root, query, builder) -> {
      // build query here
    };
  }
}

5.4 리포지터리/DAO에서 스펙 사용하기

List<Customer> customers = customerRepository.findAll(isLongTermCustomer());

5.5 스펙 조합

스펙 인터페이스는 and와 or 등 조합 메서드를 제공한다.

MonetaryAmount amount = new MonetaryAmount(200.0, Currencies.DOLLAR);
List<Customer> customers = customerRepository.findAll(
  isLongTermCustomer().or(hasSalesOfMoreThan(amount)));

null 가능성이 있는 스펙 객체의 조합은 where를 사용한다.

Specification<Customer> spec = Specification.where(createNullableSpec()).and(createOtherSpec());

5.6 정렬 지정하기

스프링 데이터 JPA는 두 가지 방법을 사용해서 정렬을 지정할 수 있다.

메서드 이름에 OrderBy를 사용해서 정렬 기준 지정
Sort를 인자로 전달

public interface OrderSummaryDao extends Repository<OrderSummary, String> {
    // OrderBy
    List<OrderSummary> findByOrdererIdOrderByNumberDesc(String ordererId);

    // Sort
    List<OrderSummary> findByOrdererId(String ordererId, Sort sort);
}

Sort sort = Sort.by(Sort.Direction.DESC, "number");
List<OrderSummary> results = orderSummaryDao.findByOrdererId("id", sort);

5.7 페이징 처리하기

스프링 데이터 JPA는 페이징 처리를 위해 Pageable 타입을 이용한다.

public interface MemberDataDao extends Repository<MemberData, String> {
    List<MemberData> findByNameLike(String name, Pageable pageable);
    Page<MemberData> findByBlocked(boolean blocked, Pageable pageable);
}

// 1은 페이지 번호, 0부터 시작한다.  10은 개수
// Sort 사용 가능
Sort sort = Sort.by(Sort.Direction.DESC, "name");
PageRequest pageReq = PageRequest.of(1, 10, sort);
List<MemberData> user = memberDataDao.findByNameLike("이름%", pageReq);

Page 리턴 타입

PageRequest pageReq = PageRequest.of(1, 5);
Page<MemberData> page = memberDataDao.findByBlocked(false, pageReq);
List<MemberData> content = page.getContent(); // 조회 결과 목록
long totalElements = page.getTotalElements(); // 조건에 해당하는 전체 개수
int totalPages = page.getTotalPages(); // 전체 페이지 번호
int number = page.getNumber(); // 현재 페이지 번호
int numberOfElements = page.getNumberOfElements() // 조회 결과 개수
int size = page.getSize(); // 페이지 크기

Page 리턴 타입은 COUNT 쿼리를 실행하므로 List만 필요한 경우 리턴 타입을 List로 한다.

5.8 스펙 조합을 위한 스펙 빌더 클래스

스펙을 조합할 때 스펙 빌더를 만들어 사용할 수 있다.

Specification<MemberData> spec = SpecBuilder.builder(MemberData.class)
                .ifTrue(searchRequest.isOnlyNotBlocked(), () -> MemberDataSpecs.nonBlocked())
                .ifHasText(searchRequest.getName(), name -> MemberDataSpecs.nameLike(searchRequest.getName()))
                .toSpec();
List<MemberData> result = memberDataDao.findAll(spec, PageRequest.of(0, 5));

public class SpecBuilder {
    public static <T> Builder<T> builder(Class<T> type) {
        return new Builder<T>();
    }

    public static class Builder<T> {
        private List<Specification<T>> specs = new ArrayList<>();

        public Builder<T> and(Specification<T> spec) {
            specs.add(spec);
            return this;
        }

        public Builder<T> ifHasText(String str,
                                    Function<String, Specification<T>> specSupplier) {
            if (StringUtils.hasText(str)) {
                specs.add(specSupplier.apply(str));
            }
            return this;
        }

        public Builder<T> ifTrue(Boolean cond,
                                 Supplier<Specification<T>> specSupplier) {
            if (cond != null && cond.booleanValue()) {
                specs.add(specSupplier.get());
            }
            return this;
        }

        public Specification<T> toSpec() {
            Specification<T> spec = Specification.where(null);
            for (Specification<T> s : specs) {
                spec = spec.and(s);
            }
            return spec;
        }
    }
}

5.9 동적 인스턴스 생성

JPQL의 new 키워드를 통해 객체를 동적으로 생성할 수 있다.

public interface OrderSummaryDao extends Repository<OrderSummary, String> {
    @Query("""    
            select new com.myshop.order.query.dto.OrderView(
                o.number, o.state, m.name, m.id, p.name
            )
            from Order o join o.orderLines ol, Member m, Product p
            where o.orderer.memberId.id = :ordererId
            and o.orderer.memberId.id = m.id
            and index(ol) = 0
            and ol.productId.id = p.id
            order by o.number.number desc
            """)
    List<OrderView> findOrderView(String ordererId);
}

5.10 하이버네이트 @Subselect 사용

@Subselect는 쿼리 결과를 @Entity로 매핑할 수 있다.
@Immutable, @Subselect, @Synchronize 와 같이 사용한다.
뷰를 수정할 수 없듯 @Subselect로 조회한 @Entity 역시 수정할 수 없다.

@Entity
@Immutable
@Subselect(
        """
        select o.order_number as number,
        o.version,
        o.orderer_id,
        o.orderer_name,
        o.total_amounts,
        o.receiver_name,
        o.state,
        o.order_date,
        p.product_id,
        p.name as product_name
        from purchase_order o inner join order_line ol
            on o.order_number = ol.order_number
            cross join product p
        where
        ol.line_idx = 0
        and ol.product_id = p.product_id"""
)
@Synchronize({"purchase_order", "order_line", "product"})
public class OrderSummary {
    @Id
    private String number;
    private long version;
    @Column(name = "orderer_id")
    private String ordererId;
    ...생략...
    protected OrderSummary() {
    }
}

6. 응용 서비스와 표현 영역

6.1 표현 영역과 응용 영역

표현 영역

표현 영역은 사용자의 요청을 해석한다.
사용자가 실행하고 싶은 기능을 판별하고 그 기능을 제공하는 응용 서비스를 실행한다.
응용 서비스가 요구하는 형식으로 사용자 요청을 변환한다.
응용 서비스의 실행 결과를 사용자에게 알맞은 형식으로 응답한다.

응용 영역

실제 사용자가 원하는 기능을 제공한다.
응용 서비스는 표현 영역에 의존하지 않는다.

6.2 응용 서비스의 역할

사용자(표현 영역)가 요청한 기능을 실행한다.
도메인 객체를 사용해서 요청을 처리한다.
도메인 객체 간의 흐름을 제어한다.
트랜잭션 처리를 담당한다.
접근 제어와 이벤트 처리를 한다.

6.2.1 도메인 로직 넣지 않기

도메인 로직은 도메인 영역에 위치하고, 응용 서비스는 도메인 로직을 구현하지 않는다.

이유

코드의 응집성이 떨어진다.
여러 응용 서비스에서 동일한 도메인 로직을 구현할 가능성이 높아진다.
결과적으로 코드 변경을 어렵게 만든다.

6.3 응용 서비스의 구현

응용 서비스는 표현 영역과 도메인 영역을 연결하는 매개체 역할을 한다.(파사드 facade)

6.3.1 응용 서비스의 크기

응용 서비스의 구현 방법은 크게 두 가지가 있다.

한 응용 서비스 클래스에 회원 도메인 모든 기능 구현하기
구분되는 기능별로 응용 서비스 클래스를 따로 구현하기(추천) 👍

// 각 응용 서비스에서 공통되는 로직을 별도 클래스로 구현
public final class MemberServiceHelper {
    public static Member findExistingMember(MemberRepository repo, String memberId) {
        Member member = memberRepository.findById(memberId);
        if (member == null) {
            throw new NoMemberException(memberId);
        }
        return member;
    }
}

// 공통 로직을 제공하는 메서드를 응용 서비스에서 사용
import static com.myshop.member.application.MemberServiceHelper.*;

public class ChangePasswordService {
    private MemberRepository memberRepository;

    public void changePassword(String memberId, String curPw, String newPw) {
        Member member = findExistingMember(memberRepository, memberId);
        member.changePassword(curPw, newPw);
    }
}

6.3.2 응용 서비스의 인터페이스와 클래스

인터페이스가 명확하게 필요하지 않다면 응용 서비스의 인터페이스 작성은 좋은 선택이 아니다. 소스 파일만 많아지고 간접 참조가 증가해서 전체 구조가 복잡해진다.

인터페이스가 필요한 상황

구현 클래스가 여러개인 경우

6.3.3 메서드 파라미터와 값 리턴

도메인을 이용해 기능을 실행하는 데 필요한 값을 파라미터로 전달받아야 한다.
각 값을 개별 파라미터로 전달받을 수도 있고 DTO를 만들어 전달받을 수도 있다.
응용 서비스의 결과를 표현 영역에서 사용해야 한다면, 응용 서비스의 결과로 필요한 데이터를 리턴한다.
애그리거트 자체를 리턴하는 것은 응집도를 낮추어 비추천한다.

6.3.4 표현 영역에 의존하지 않기

표현 영역에 해당하는 HttpServletRequest, HttpSession 등을 응용 서비스에에 파라미터로 전달하면 안 된다.

private ChangePasswordService changePasswordService;

@PostMapping
public String sumbit(HttpServletRequest request) {
    // 응용 서비스가 표현 영역을 의존하면 안된다.
    changePasswordService.changePassword(request);
    ...생략...
}

6.3.5 트랜잭션 처리

스프링과 같은 프레임워크가 제공하는 트랜잭션 관리 기능을 이용한다.

@Transactional

6.4 표현 영역

사용자가 시스템을 사용할 수 있는 흐름(화면)을 제공하고 제어한다.
사용자의 요청을 알맞은 응용 서비스에 전달하고 결과를 사용자에게 제공한다.
사용자의 세션을 관리한다.

6.5 값 검증

값 검증은 표현 영역과 응용 서비스 두 곳에서 모두 수행할 수 있다. 원칙적으로는 응용 서비스에서 처리한다.

응용 서비스를 사용하는 표현 영역의 코드가 한 곳이면 구현의 편리함을 위해 다음과 같이 역할을 나누어 검증을 수행할 수도 있다.

표현 영역: 필수 값, 값의 형식, 범위 등을 검증한다.
응용 서비스: 데이터의 존재 유무와 같은 논리적 오류를 검증한다.

6.6 권한 검사

다음 세 곳에서 권한 검사를 수행할 수 있다.

표현 영역
- 서블릿 필터
응용 서비스
- AOP
도메인
- 직접 로직 구현

// 스프링 시큐리티 활용
@PreAuthorize("hasRole('ADMIN')")

6.7 조회 전용 기능과 응용 서비스

응용 서비스가 사용자 요청 기능을 실행하는 데 별다른 기여를 하지 못한다면 굳이 서비스를 만들지 않아도 된다.

응용서비스생략

7. 도메인 서비스

7.1 여러 애그리거트가 필요한 기능

한 애그리거트에 넣기 애매한, 여러 애그리거트가 필요한 기능이라면 별도 도메인 서비스로 구현한다.

7.2 도메인 서비스

도메인 서비스는 도메인 영역에 위치한 도메인 로직을 표현할 때 사용한다. 주로 다음 상황에서 도메인 서비스를 사용한다.

계산 로직: 여러 애그리거트가 필요한 계산로직이나, 한 애그리거트에 넣기에는 다소 복잡한 계산 로직
외부 시스템 연동이 필요한 도메인 로직: 구현하기 위해 타 시스템을 사용해야 하는 도메인 로직

7.2.1 계산 로직과 도메인 서비스

도메인 서비스를 사용하는 주체

애그리거트
응용 서비스

// 애그리거트가 사용
public class OrderService {
    // 도메인 서비스
    private DiscountCalculationService discountCalculationService;

    private Order createOrder(OrderNo orderNo, OrderRequest orderReq) {
        Member member = findMember(orderReq.getOrdererId());
        Order order = new Order(orderNo, ...생략);
        // 애그리거트 객체에 도메인 서비스 전달
        order.calculateAmounts(this.discountCalculationService, member.getGrade());
    }
}

// 응용 서비스가 사용
public class TransferService { // 도메인 서비스

    // 도메인 서비스의 기능을 실행할 때 애그리거트를 전달
    public void transfer(Account fromAcc, Account toAcc, Money amounts) {
        fromAcc.withdraw(amounts);
        toAcc.credit(amounts);
    }
    ...
}

특정 기능이 응용 서비스인지 도메인 서비스인지 확인하는 방법

아래의 행위가 일어나면 도메인 서비스

애그리거트의 상태를 변경
애그리거트의 상태 값을 계산

7.2.2 외부 시스템 연동과 도메인 서비스

시스템 간 연동은 HTTP API 호출로 이루어질 수 있지만, 도메인 입장에서는 도메인 로직으로 볼 수 있다. 도메인 관점에서 인터페이스를 작성한다.

// 도메인 서비스
public interface SurveyPermissionChecker {
    boolean hasUserCreationPermission(String userId);
}

//응용 서비스는 도메인 서비스를 이용
public class CreateSurveyService {
    private SurveyPermissionChecker surveyPermissionChecker;

    public Long createSurvey(CreateSurveyRequest req) {
        validate(req);

        // 도메인 서비스를 이용해서 외부 시스템 연동을 표현
        if (surveyPermissionChecker.hasUserCreationPermission(req.getRequestorId())) {
            throw new NoPermissionException();
        }
        ...생략...
    }
}

SurveyPermissionChecker 인터페이스를 구현한 클래스는 인프라스트럭처 영역에 위치한다.

7.2.3 도메인 서비스의 패키지 위치

도메인 서비스의 개수가 많거나 명시적으로 구분하고 싶다면 아래와 같이 하위 패키지로 구분한다.

domain
- domain.model
- domain.service
- domain.repository

7.2.4 도메인 서비스의 인터페이스와 클래스

도메인 서비스의 로직이 고정되어 있지 않은 경우 도메인 서비스 자체를 인터페이스로 구현하고 이를 구현한 클래스를 둘 수도 있다.

8. 애그리거트 트랜잭션 관리

8.1 애그리거트와 트랜잭션

트랜잭션 처리 방식

선점 잠금 (Pessimistic Lock, 비관적 잠금)
비선점 잠금 (Optimistic Lock, 낙관적 잠금)

8.2 선점 잠금

// JPA
Order order = entityManager.find(Order.class, orderNo, LockModeType.PESSIMISTIC_WRITE);

// 스프링 데이터 JPA
public interface MemberREpository extends Repository<Member, MemberId> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    Optional<Member> findById(MemberId memberId);
}

8.2.1 선점 잠금과 교착 상태

다음 상황은 교착 상태에 빠진다.

스레드 1: 🐳 애그리거트에 대한 선점 잠금 구함
스레드 2: 🦍 애그리거트에 대한 선점 잠금 구함
스레드 1: 🦍 애그리거트에 대한 선점 잠금 시도
스레드 2: 🐳 애그리거트에 대한 선점 잠금 시도

해결 방법
힌트를 제공해 최대 대기시간을 지정한다.

// JPA
Map<String, Object> hints = new HashMap<>();
hints.put("javax.persistence.lock.timeout", 2000);
Order order = entityManager.find(Order.class, orderNo, LockModeType.PESSIMISTIC_WRITE, hints);

// 스프링 데이터 JPA
public interface MemberREpository extends Repository<Member, MemberId> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @QueryHints({
        @QueryHint(name = "javax.persistence.lock.timeout", value = "2000")
    })
    Optional<Member> findById(MemberId memberId);
}

DBMS에 따라 교착 상태에 빠진 커넥션을 처리하는 방식이 다르다. 사용하는 DBMS에 대해 JPA가 어떤 식으로 대기시간을 처리하는지 반드시 확인해야 한다.

8.3 비선점 잠금

선점 잠금으로 모든 트랜잭션 충돌 문제가 해결되는 것은 아니다

비선점 잠금은 동시에 접근하는 것을 막는 대신 변경한 데이터를 실제 DBMS에 반영하는 시점에 변경 가능 여부를 확인하는 방식이다.

비선점 잠금을 구현하려면 애그리거트에 버전으로 사용할 숫자 타입 프로퍼티를 추가해야 한다. 애그리거트를 수정할 때마다 버전으로 사용할 프로퍼티 값이 1씩 증가한다.

// JPA
@Entity
@Table(name = "purchase_order")
@Access(AccessType.FIELD)
public class Order {
    ...생략...
    @Version
    private long version;
    ...생략...
}

JPA 엔티티가 변경되어 UPDATE 쿼리를 실행할 때 @Version에 명시한 필드를 이용해서 비선점 잠금 쿼리를 실행한다. 응용 서비스는 버전에 대해 알 필요가 없다.

트랜잭션 충돌이 발생하면 OptimisticLockingFailureException이 발생한다.

비선점 잠금 확장

비선점 잠금 방식을 여러 트랜잭션으로 확장하려면 애그리거트 버전 정보를 응용 서비스에 전달한다. 응용 서비스는 전달받은 버전 값을 이용해서 애그리거트 버전과 일치하는지 확인하고, 일치하는 경우에만 기능을 수행한다.

public class StartShippingRequest {
    private String orderNumber;
    private long version;
    ...생략...
}

// 응용 서비스
public StartShippingService {

    @PreAuthorize("hasRole('ADMIN')")
    @Transactional
    public void startShipping(StartShippingRequest req) {
        Order order = orderRepository.findById(new OrderNo(req.getOrderNumber()));
        // version 확인
        if (!order.matchVersion(req.getVersion())) {
            throw new VersionConflictException();
        }
        ...생략...
    }
}

8.3.1 강제 버전 증가

기능 실행 도중 루트가 아닌 다른 엔티티의 값만 변경된다면, JPA는 루트 엔티티 버전 값을 증가시키지 않는다.

JPA는 이런 문제를 처리할 수 있도록 EntityManager#find() 메서드로 엔티티를 구할 때 강제로 버전 값을 증가시키는 잠금 모드를 지원한다. LockModeType.OPTIMISTIC_FORCE_INCREMENT를 사용하면 해당 엔티티의 상태가 변경되었는지에 상관없이 트랜잭션 종료 시점에 버전 값 증가 처리를 한다.

// JPA
Order order = entityManager.find(Order.class, orderNo, LockModeType.OPTIMISTIC_FORCE_INCREMENT);

// 스프링 데이터 JPA
public interface MemberREpository extends Repository<Member, MemberId> {

    @Lock(LockModeType.OPTIMISTIC_FORCE_INCREMENT)
    Optional<Member> findById(MemberId memberId);
}

8.4 오프라인 선점 잠금

누군가 수정 화면을 보고 있을 때 수정 화면 자체를 실행하지 못하게 하는 것이 오프라인 선점 잠금 방식이다.

8.4.1 오프라인 선점 잠금을 위한 LockManager 인터페이스와 관련 클래스

필요 기능

잠금 선점 시도
잠금 확인
잠금 해제
잠금 유효시간

구현 코드는 책에서 확인해주세요. 🔎

8.4.2 DB를 이용한 LockManager 구현

구현 코드는 책에서 확인해주세요. 🔎

9. 도메인 모델과 바운디드 컨텍스트

9.1 도메인 모델과 경계

논리적으로 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우도 있다.

이렇게 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없다.

모델은 특정한 컨텍스트(문맥) 하에서 완전한 의미를 갖는다. 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다르다. 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 바운디드 컨텍스트(Bounded Context)라고 부른다.

9.2 바운디드 컨텍스트

도메인 모델의 경계를 결정한다.
용어를 기준으로 구분한다.
한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖는다.
한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도, 하위 도메인마다 구분되는 패키지를 갖도록 구현해야 한다.

아직 명확하게 구분되지 않은 경우 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.
바운디드컨텍스트

한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도, 하위 도메인마다 구분되는 패키지를 갖도록 구현해야 한다.
바운디드컨텍스트

같은 상품이라도 각자 구현하는 하위 도메인에 맞는 모델을 갖는다.
바운디드컨텍스트

9.3 바운디드 컨텍스트 구현

바운디드 컨텍스트는 도메인 기능을 사용자에게 제공하는 데 필요한 표현 영역, 응용 서비스, 인프라스트럭처, 테이블 영역을 포함한다.

CQRS (Command Query Responsibility Segregation, 명령 조회 책임 분리) 패턴을 사용할 수도 있다.

바운디드 컨텍스트는 UI를 갖지 않을 수도 있다.

바운디드 컨텍스트는 UI서버를 통해 간접적으로 브라우저와 통신할 수도 있다. 여기서 UI서버는 파사드 역할을 수행한다.

9.4 바운디드 컨텍스트 간 통합

바운디드 컨텍스트 간 통합이 필요할 때도 있다.

REST API를 이용한 직접 통합

통신

바운디드컨텍스트간통합

도메인에 맞는 모델로 변환

바운디드컨텍스트간통합

메시지 큐를 사용하여 통합 바운디드컨텍스트간통합

바운디드컨텍스트간통합

마이크로서비스와 바운디드 컨텍스트
마이크로서비스는 애플리케이션을 작은 서비스로 나누어 개발하는 아키텍처 스타일이다. 개별 서비스를 독립된 프로세스로 실행하고 각 서비스가 REST API나 메시징을 이용해서 통신하는 구조를 갖는다.

바운디드 컨텍스트를 마이크로서비스로 구현하면 자연스럽게 컨텍스트별로 모델이 분리된다. 마이크로서비스마다 프로젝트를 생성하므로 바운디드 컨텍스트마다 프로젝트를 만들게 된다. 이것은 코드 수준에서 모델을 분리하여 두 바운디드 컨텍스트의 모델이 섞이지 않도록 해준다.

9.5 바운디드 컨텍스트 간 관계

바운디드 컨텍스트는 어떤 식으로든 연결되기 때문에 두 바운디드 컨텍스트는 다양한 방식으로 관계를 맺는다.

REST API
바운디드컨텍스트간통합

단일 API
바운디드컨텍스트간통합

독립 방식
그냥 서로 통합하지 않는 방식이다. 서로 독립적으로 모델을 발전 시킨다. 하지만 규모가 커질수록 한계가 있으므로 그 전에 두 바운디드 컨텍스트를 통합해야 한다.

바운디드컨텍스트간통합

9.6 컨텍스트 맵

개별 바운디드 컨텍스트에 매몰되면 전체를 보지 못할 때가 있다. 전체 바운디드 컨텍스트 간 관계를 볼 수 있는 지도가 필요한데 그것이 바로 컨텍스트 맵이다.

컨텍스트맵

10. 이벤트

10.1 시스템 간 강결합 문제

트렌젝션 문제
외부 서비스의 성능에 영향을 받음
설계상 문제 (로직이 섞임)
기능 추가의 어려움

10.2 이벤트 개요

여기서 사용되는 이벤트라는 용어는 ‘과거에 벌어진 어떤 것’을 의미한다.

이벤트 발생
이벤트에 반응하여 동작 수행

10.2.1 이벤트 관련 구성요소

이벤트
이벤트 생성 주체
이벤트 디스패처 (퍼블리셔)
이벤트 핸들러 (구독자)

이벤트구성요소

도메인 모델에서 이벤트 생성 주체는 엔티티, 밸류, 도메인 서비스와 같은 도메인 객체이다. 도메인 객체는 도메인 로직을 실행해서 상태가 바뀌면 관련 이벤트를 발생시킨다.

10.2.2 이벤트의 구성

이벤트는 발생한 이벤트에 대한 정보를 담는다.

이벤트 종류: 클래스 이름으로 이벤트 종류를 표현
이벤트 발생 시간
추가 데이터: 주문번호, 시규배송지 정보 등 이벤트와 관련된 정보

10.2.3 이벤트 용도

후처리를 실행하기 위한 트리거
서로 다른 시스템 간의 데이터 동기화

이벤트용도

10.2.4 이벤트 장점

서로 다른 도메인 로직이 섞이는 것을 방지
도메인 로직에 영향 없이 기능 확장

이벤트장점

10.3 이벤트, 핸들러, 디스패처 구현

이벤트와 관련된 코드

이벤트 클래스: 이벤트를 표현한다.
디스패처: 스프링이 제공하는 ApplicationEventPublisher를 이용한다.
Events: 이벤트를 발행한다. 이벤트 발행을 위해 ApplicationEventPublisher를 사용한다.
이벤트 핸들러: 이벤트를 수신해서 처리한다. 스프링이 제공하는 기능을 사용한다.

10.3.1 이벤트 클래스

// 공통 추상 클래스
package com.myshop.common.event;

public abstract class Event {
    private long timestamp;

    public Event() {
        this.timestamp = System.currentTimeMillis();
    }
    ...생략...
}

public class OrderCanceledEvent extends Event {

    // 이벤트는 핸들러에서 이벤트를 처리하는 데 필요한 데이터를 포함
    private String orderNumber;

    public OrderCanceledEvent(String number) {
        super();
        this.orderNumber = number;
    }
    ...생략...
}

10.3.2 Events 클래스와 ApplicationEventPublisher

이벤트 발생과 출판을 위해 스프링이 제공하는 ApplicationEventPublisher를 사용한다.

// 설정
@Configuration
public class EventsConfiguration {
    @Autowired
    private ApplicationContext applicationContext;

    @Bean
    public InitializingBean eventsInitializer() {
        return () -> Events.setPublisher(applicationContext);
    }
}

// Events는 ApplicationEventPublisher를 사용해서 이벤트를 발생
public class Events {
    private static ApplicationEventPublisher publisher;

    static void setPublisher(ApplicationEventPublisher publisher) {
        Events.publisher = publisher;
    }

    public static void raise(Object event) {
        if (publisher != null) {
            publisher.publishEvent(event);
        }
    }
}

10.3.3 이벤트 발생과 이벤트 핸들러

// 이벤트 발생
public class Order {
    public void cancel() {
        ...생략...
        Events.raise(new OrderCanceledEvent(number.getNumber()));
    }
}

// 이벤트 핸들러
@Service
public class OrderCanceledEventHandler {
    private RefundService refundService;

    public OrderCanceledEventHandler(RefundService refundService) {
        this.refundService = refundService;
    }

    @EventListener(OrderCanceledEvent.class)
    public void handle(OrderCanceledEvent event) {
        refundService.refund(event.getOrderNumber());
    }
}

10.3.4 흐름 정리

이벤트흐름

10.4 동기 이벤트 처리 문제

동기 이벤트 처리는 다음과 같은 문제가 발생한다.

외부 연동 과정에서 익셉션이 발생하면 트랜잭션 처리는?
이벤트 처리하는 코드가 느려지거나 익셉션이 발생하면?

10.5 비동기 이벤트 처리

비동기 이벤트 처리로 해결한다.

로컬 핸들러를 비동기로 실행하기
메시지 큐를 사용하기
이벤트 저장소와 이벤트 포워더 사용하기
이벤트 저장소와 이벤트 제공 API 사용하기

10.5.1 로컬 핸들러 비동기 실행

이벤트 핸들러를 별도 스레드로 실행한다. 스프링이 제공하는 @Async 에너테이션을 사용하면 손쉽게 비동기로 이벤트 핸들러를 실행할 수 있다.

@SpringBootApplication
@EnableAsync  // 기능 활성화
public class ShopApplication {

    public static void main(String[] args) {
        SpringApplication.run(ShopApplication.class, args);
    }
}

// 핸들러
@Service
public class OrderCanceledEventHandler {

    @Async // @Async 에너테이션 사용
    @EventListener(OrderCanceledEvent.class)
    public void handle(OrderCanceledEvent event) {
        refundService.refund(event.getOrderNumber());
    }
}

10.5.2 메시징 시스템을 이용한 비동기 구현

Kafka나 RabbitMQ와 같은 메시징 시스템을 사용

RabbitMQ
- 글로벌 트랜잭션 지원
Kafka
- 글로벌 트랜잭션 지원 X
- 다른 메시징 시스템에 비해 높은 성능

이벤트메시지큐

10.5.3 이벤트 저장소를 이용한 비동기 처리

이벤트를 일단 DB에 저장한 뒤에 별도 프로그램을 이용해서 이벤트 핸들러에 전달

이벤트저장소이용포워더

이벤트저장소이용API

API방식과 포워더 방식의 차이점은 이벤트를 전달하는 방식에 있다.

포워더
- 포워더를 이용해서 이벤트를 외부에 전달.
- 이벤트를 어디까지 처리했는지 추적하는 역할이 포워더에 있다.
API
- 외부 핸들러가 API 서버를 통해 이벤트 목록을 가져감.
- 이벤트를 어디까지 처리했는지 추적하는 역할이 외부 핸들러에 있다.

구현 방법은 책 참고
…생략…😅

자동 증가 칼럼 주의 사항
트랜잭션 커밋 시점에 따른 자동 증가 칼럼 문제
자동 증가 칼럼 주의 사항 링크

// 트랜잭션 커밋 시점에 따른 ID 값
시간 흐름 --->  
트랜잭션 1: 1, 2       5, 6
트랜잭션 2:       3, 4      7, 8

10.6 이벤트 적용 시 추가 고려 사항

이벤트 적용 시 다음 고려사항을 생각해본다.

이벤트 소스를 EventEntry에 추가할지?
- EventEntry는 이벤트 발생 주체에 대한 정보를 갖지 않는다.
- 특정 주체가 발생시킨 이벤트만 조회하는 기능을 구현할 수 없다.
- 이 기능을 구현하려면 이벤트에 발생 주체 정보를 추가해야 한다.
포워더에서 전송 실패를 얼마나 허용할지?
- 포워더는 이벤트 전송에 실패하면 실패한 이벤트부터 다시 읽어와 전송을 시도한다.
- 특정 이벤트가 계속 실패한다면?
- 실패한 이벤트의 재전송 횟수 제한을 두어야 한다.
- 실패한 이벤트는 실패용 DB나 메시지 큐에 저장한다.
이벤트 손실은?
- 이벤트 저장소를 사용하면 이벤트 발생과 이벤트 저장을 한 트랜잭션으로 처리하기 때문에 트랜잭션에 성공하면 이벤트가 저장소에 보관된다는 것을 보장할 수 있다.
- 이벤트를 비동기로 처리할 경우 이벤트 처리에 실패하면 이벤트를 유실하게 된다.
이벤트 순서는?
- 이벤트 발생 순서대로 외부 시스템에 전달해야 할 경우는 이벤트 저장소를 사용한다.
- 메시징 시스템은 사용 기술에 따라 이벤트 발생 순서와 메시지 순서가 다를 수 있다.
이벤트 재처리는?
- 이벤트의 순번을 기억한다.
- 이벤트 멱등성으로 처리한다

멱등성이란?
연산을 여러번 적용해도 결과가 달라지지 않는 성질을 멱등성이라고 한다.

10.6.1 이벤트 처리와 DB 트랜잭션 고려

이벤트 처리를 동기로 하든 비동기로 하든 이벤트 처리 실패와 트랜잭션 실패를 함께 고려해야 한다. 트랜잭션 실패와 이벤트 처리 실패 모두 고려하면 복잡해지므로 경우의 수를 줄이면 도움이 된다. 경우의 수를 줄이는 방법은 트랜잭션이 성공할 때만 이벤트 핸들러를 실행하는 것이다.

스프링은 @TransactionalEventListener 에너테이션을 지원한다. 이 애너테이션은 트랜잭션 상태에 따라 이벤트 핸들러를 실행할 수 있게 한다.

@TransactionalEventListener(
        classes = OrderCanceledEvent.class,
        phase = TransactionPhase.AFTER_COMMIT
)
public void handle(OrderCanceledEvent event) {
    refundService.refund(event.getOrderNumber());
}

11. CQRS

11.1 단일 모델의 단점

조회 기능을 구현하려면 여러 애그리거트에서 데이터를 가져와야 할 경우가 많다. 이 때 식별자를 이용한 참조 방식이든, 직접 참조하는 방식이든 고민해야 할 것들이 많다. 이는 구현 복잡도를 높인다.

이런 구현 복잡도를 낮추는 간단한 방법이 바로 CQRS (Command Query Responsibility Segregation, 명령 조회 책임 분리)다.

11.2 CQRS

CQRS패턴

CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다.

CQRS

CQRS_2

단순히 데이터를 읽어와 조회하는 기능은 응용 서비스를 제외할 수도 있다.

CQRS를 사용하면 각 모델에 맞는 데이터 저장소를 선택할 수 있다.

CQRS

명령 모델은 트랜잭션을 지원하는 RDBMS를 사용하고, 조회 모델은 조회 성능이 좋은 메모리 기반 NoSQL을 사용할 수 있다.

11.2.1 웹과 CQRS

일반적인 웹 서비스는 상태를 변경하는 요청보다 상태를 조회하는 요청이 많다. 대규모 트래픽이 발생하는 웹 서비스는 알게 모르게 CQRS를 적용하게 된다. 조회 속도를 높이기 위해 별도 처리를 하고 있다면 CQRS를 적용하자. 이를 통해 조회 기능 때문에 명령 모델이 복잡해지는 것을 막을 수 있고, 명령 모델에 관계없이 조회 기능에 특화된 구현 기법을 보다 쉽게 적용할 수 있다.

11.2.2 CQRS 장단점

장점
- 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다.
- 조회 성능 향상에 유리
단점
- 구현해야 할 코드가 더 많다.
- 더 많은 구현 기술이 필요하다.

장단점을 고려해 CQRS 패턴 도입 여부를 결정한다. 도메인이 복잡하지 않은데 CQRS를 도입하면 유지 비용만 높아진다. 반면 트래픽이 높은 서비스인데 단일 모델을 고집하면 유지 보수 비용이 오히려 높아질 수 있으므로 CQRS 도입을 고려하자.

감사합니다 🙇🏻‍♂️

Twitter Facebook LinkedIn

Oh

1. 도메인 모델 시작하기

1.1 도메인이란?

1.2 도메인 전문가와 개발자 간 지식공유

1.3 도메인 모델

1.4 도메인 모델 패턴

1.5 도메인 모델 도출

1.6 엔티티와 벨류

1.6.1 엔티티

1.6.2 엔티티의 식별자 생성

1.6.3 밸류 타입

1.6.4 엔티티 식별자와 밸류 타입

1.6.5 도메인 모델에 set 넣지 않기

1.7 도메인 용어와 유비쿼터스 언어

2. 아키택처 개요

2.1 네 개의 영역

2.2 계층 구조 아키텍처

2.3 DIP

2.4 도메인 영역의 주요 구성요소

2.5 요청 처리 흐름

2.6 인프라스트럭처 개요

2.7 모듈 구성

3. 애그리거트

3.1 애그리거트

3.2 애그리거트 루트

3.2.1 도메인 규칙과 일관성

3.2.2 애그리거트 루트의 기능 구현

3.2.3 트랜젝션 범위

3.3 리포지터리와 애그리거트

3.4 ID를 이용한 애그리거트 참조

3.4.1 ID를 이용한 참조와 조회 성능

3.5 애그리거트 간 집합 연관

3.6 애그리거트를 팩토리로 사용하기

4. 리포지터리와 모델 구현

4.1 JPA를 이용한 리포지터리 구현

4.1.1 모듈 위치

4.1.2 리포지터리 기본 기능 구현

4.2 스프링 데이터 JPA를 이용한 리포지터리 구현

4.3 매핑 구현

4.3.1 엔티티와 밸류 기본 매핑 구현

4.3.2 기본 생성자

4.3.2 필드 접근 방식 사용

4.3.4 AttributeConverter를 이용한 밸류 매핑 처리

4.3.5 밸류 컬렉션: 별도 테이블 매핑

4.3.6 밸류 컬렉션: 한 개 컬럼 매핑

4.3.7 밸류를 이용한 ID 매핑

4.3.8 별도 테이블에 저장하는 밸류 매핑

4.3.9 밸류 컬렉션을 @Entity로 매핑하기

4.3.10 ID 참조와 조인 테이블을 이용한 단방향 M-N 매핑

4.4 애그리거트 로딩 전략

4.5 애그리거트 영속성 전파

4.6 식별자 생성 기능

4.7 도메인 구현과 DIP

5. 스프링 데이터 JPA를 이용한 조회 기능

5.1 시작에 앞서

5.2 검색을 위한 스펙

5.3 스프링 데이터 JPA를 이용한 스펙 구현

5.4 리포지터리/DAO에서 스펙 사용하기

5.5 스펙 조합

5.6 정렬 지정하기

5.7 페이징 처리하기

5.8 스펙 조합을 위한 스펙 빌더 클래스

5.9 동적 인스턴스 생성

5.10 하이버네이트 @Subselect 사용

6. 응용 서비스와 표현 영역

6.1 표현 영역과 응용 영역

6.2 응용 서비스의 역할

6.2.1 도메인 로직 넣지 않기

6.3 응용 서비스의 구현

6.3.1 응용 서비스의 크기

6.3.2 응용 서비스의 인터페이스와 클래스

6.3.3 메서드 파라미터와 값 리턴

6.3.4 표현 영역에 의존하지 않기

6.3.5 트랜잭션 처리

6.4 표현 영역

6.5 값 검증

6.6 권한 검사

6.7 조회 전용 기능과 응용 서비스

7. 도메인 서비스

7.1 여러 애그리거트가 필요한 기능