TIL

5장 비즈니스 로직 설계

5.1 비즈니스 로직 구성 패턴

• 주문 서비스는 육각형 아키텍처 구조
  • 중심에 비즈니스 로직이 존재
  • 인바운드/아웃바운드 어댑터가 주변을 감싸고 있다.
• 주문 서비스는 비즈니스 로직과 다음 어댑터로 구성
  • REST API 어댑터: 비즈니스 로직을 호출하는 REST API가 구현된 인바운드 어댑터
  • OrderCommandHandlers: 메시지 채널에서 들어온 커맨드 메시지를 받아 비즈니스 로직을 호출하는 인바운드 어댑터
  • DB 어댑터: 비즈니스 로직이 DB 접근을 위해 호출하는 아웃바운드 어댑터
  • 도메인 이벤트 발행 어댑터: 이벤트를 메시지 브로커에 발행하는 아웃바운드 어댑터

5.1.1 비즈니스 로직 설계: 트랜잭션 스크립트 패턴

• 트랜잭션 스크립트 패턴
  • 객체 지향 설계를 하지 않고 트랜잭션 스크립트라는 메서드를 작성해 표현 계층의 요청을 처리하는 것
  • 동작이 구현된 클래스와 상태를 보관하는 클래스가 따로 존재
    • 동작 클래스: OrderServce, OrderDao
    • 상태 클래스: Order
  • 복잡한 비즈니스 로직이 아닌 단순한 비즈니스 로직에는 아주 잘 통한다.

5.1.2 비즈니스 로직 설계: 도메인 모델 패턴

• 비즈니스 로직이 복잡해지면 도메인 모델 패턴을 응용햔 객체 지향 설계를 하는 것이 좋다.
• 대부분의 클래스가 상태/동작 모두 갖고 있다.
• 도메인 모델 패턴을 적용하면 서비스 메서드가 단순해진다.
  • 서비스 메서드는 DB에서 도메인 객체를 로드하고 메서드 중 하나를 호출
  • 동작/상태를 모두 가진 Order 클래스의 상태 값은 프라이빗하기에 메서드를 통한 간접 접근만 가능
• 객체 지향 설계의 장점
  • 설계를 이해/관리하기 쉽다.
  • 테스트하기 쉽다.
  • 잘 알려진 설계 패턴을 응용할 수 있어 확장이 쉽다.

5.1.3 도메인 주도 설계 개요

• DDD(Domain-Driven Design)는 복잡한 비즈니스 로직 개발을 위한 방식이다.
  • 하위 도메인과 경계 컨텍스트 개념은 DDD 패턴의 양대 전략
• DDD에서 흔히 쓰이는 빌딩 블록
  • 엔티티: 영속성 신원을 가진 객체. 두 엔티티는 속성 값이 동일해더 엄연히 다른 객체
  • 벨류 객체: 여러 값을 모아 놓은 객체로 속성 값이 동일한 두 벨류 객체는 동일하게 취급 (ex Money 클래스)
  • 팩토리: 일반 생성자로 직접 만들기 복잡한 객체 생성 로직이 구현된 객체 또는 메서드
  • 리포지터리: 엔티티를 저장하는 DB 접근 로직을 캡슐화한 객체
  • 서비스: 엔티티, 벨류 객체에 속하지 않은 비즈니스 로직 구현 객체
• 이 외에도 ‘애그리거트’라는 빌딩 블록이 존재한다.

5.2 도메인 모델 설계: DDD 애그리거트 패턴

• 전통적인 객체 지향 기반 도메인 모델은 클래스 간 관계를 모은 것이다.
  • 클래스는 보통 패키지로 구성
• 기존 도메인 모델에선 비즈니스 객체들의 경계가 불분명한 문제가 있다.

5.2.1 불분명한 경계 문제

• Order 비즈니스 객체에 어떤 작업을 수행한다고 하자.
  • 당연히 Order 객체를 조회하거나 변경을 일으킬 것이다.
  • 하지만 Order 뿐 아니라 주문 품목, 지불 정보 등 다른 연관 데이터도 많다.
  • 이렇게 개념이 모호하면 비즈니스 객체를 업데이트할 때 문제가 생길 수 있다.
• ex) 여러 소비자가 주문하는 상황에서 최소 주문량 충족 여부
  • Order 객체는 ’최소 주문량’이라는 불변 값이 있어서 주문을 업데이트할 때 이 값 이상을 주문해야 한다.
  • 두 소비자가 주문을 하는 동시에 주문이 본인의 예산을 초과했는지 결정한다고 가정

  • 아래의 트랜잭션 들은 별도의 UI 시나리오에서 진행

    소비자1                                 소비자 2                 
        
    BEGIN TXN                             BEGIN TXN
        주문 ID로 주문 조회                       주문 ID로 주문 조회
        주문 ID로 주문 품목 조회                   주문 ID로 주문 품목 조회
        ...                                   ...
    END TXN                               END TXN
        
    최소 주문량이 충족됨을 확인
        
    BEGIN TXN
        주문 품목 수량을 낙관적 락을 통해 업데이트
    END TXN                               최소 주문량이 충족됨을 확인함
        
                                          BEGIN TXN
                                              주문 품목 수량을 낙관적 락을 통해 업데이트
                                          END TXN  
    

  • ‘주문’과 ‘주문 품목’을 조회 후 최소 주문량이 충족됨을 확인
  • ‘주문 품목’ 수량을 조절하여 주문 금액을 낮춤
    • Order는 최소 주문량을 못맞추게 되어 더 이상 유효하지 않게 됨
  • 애플리케이션은 두 소비자의 주문이 최소 주문량 조건을 충족한다고 간주하여 주문을 진행
• 위처럼 비즈니스 객체 일부를 직접 업데이트하면 결과적으로 비즈니스 규칙을 위반하게 된다.

5.2.2 애그리거트는 경계가 분명하다

• 애그리거트란 한 단위로 취급 가능한 경계 내부 도메인 객체
  • 하나의 루트 엔티티와 하나 이상의 기타 엔티티 + 벨류 객체로 구성

• Order 애그리거트와 그 경계

  

  • Order는 애그리거트 루트이며 DeliveryInfo, PaymentInfo, OrderLineItem은 벨류 객체
• 애그리거트는 도메인 모델을 개별적으로 이해하기 쉬운 덩어리(chunk)로 분해한다.
  • 수정, 삭제 같은 작업 범위를 분명하게 설정
  • 작업은 애그리거트 일부가 아닌 전체 애그리거트에 적용
• 애그리거트는 보통 DB에서 통째로 가져오기에 복잡한 지연 로딩 문제를 신경 쓸 필요가 없다.
  • 애그리거트를 삭제하면 해당 객체가 모두 사라진다.
• 일부가 아닌 전체 애그리거트를 업데이트하므로 일관성 문제가 해소된다.
  • 업데이트는 루트 엔티티에서 호출되기에 불변 값이 강제되고 동시성 역시 루트를 잠금하여 처리
  • ex) 클라이언트가 직접 품목을 수정할 수 없고 반드시 주문 애그리거트 루트의 메서드를 호출해야 하기에 불변성이 강제된다.
• 애그리거트를 식별하는 일이 관건
  • DDD의 핵심은 애그리거트와 그 경계 그리고 루트를 식별하는 것
    • 애그리거트 내부 상세 구조는 부차적 문제
  • 애그리거트는 규칙을 반드시 준수해야 하기에 도메인 모델 모듈화뿐 아니라 장점이 무궁무진하다.

5.2.3 애그리거트 규칙

• 애그리거트 규칙을 지켜야 불변을 강제하는 자기 완비형 단위가 된다.

규칙 #1: 애그리거트 루트만 참조하라

• 외부 클래스는 반드시 애그리거트 루트 엔티티만 참조해야 한다.
  • ‘주문 품목’(OrderLineItem)을 직접 건드리면 위험한 이유는 위 예제에서 설명했다.
  • 루트 엔티티만 호출해 애그리거트를 업데이트해야 한다.

규칙 #2: 애그리거트 간 참조는 반드시 기본키를 사용하라

• 애그리거트는 객체 레퍼런스 대신 기본키로 서로 참조해야 한다.
  • Order는 다른 루트 엔티티인 Cunsumer 객체 대신 consumerId로 참조해야 한다.
• 기존 객체 모델링에서 ID 참조는 나쁘다고 했지만 여러모로 장점이 많다.
  • 애그리거트가 느슨하게 결합되고 경계가 분명해진다.
  • 실수로 다른 애그리거트를 업데이트하지 않게 된다.
  • 애그리거트가 다른 서비스의 일부인 경우에도 여러 서비스에 걸친 객체 레퍼런스는 문제 없다.
  • 애그리거트 그 자체가 저장 단위이기에 저장 로직도 간단해진다.
  • 지연 로딩을 투명하게 처리할 필요와 그로 인한 부작용도 없다.
  • DB를 확장할 때도 애그리거트를 샤딩하는 편이 더 알기 쉽다.

규칙 #3: 하나의 트랜잭션으로 하나의 애그리거트를 생성/수정하라

• 하나의 트랜잭션으로 오직 하나의 애그리거트만 수정해야 한다.
  • 모놀리식 애플리케이션에선 여러 애그리거트를 업데이트하는 경우가 많을 것이다.
  • 하지만 이 제약은 MSA와 완벽하게 맞아 떨어진다.
• 단 이 규칙을 지키려면 애그리거트의 생성/수정 작업이 조금 복잡해진다.
  • 이를 사가 패턴으로 해결하게 된다.
  • 사가의 각 단계는 정확히 하나의 애그리거트만을 수정한다.
• 여러 애그리거트를 한 트랜잭션으로 업데이트하는 방법도 있다.
  • 한 서비스에서 두 애그리거트를 한 트랜잭션으로 업데이트
  • 트랜잭션이 잘 지원되는 RDBMS에서만 가능하고 NoSQL에선 사가 외엔 방법이 없다.
• 애그리거트 경계는 고정 불변이 아니다.
  • 경계선을 어디에 그을지 잘 선택해야 한다.

5.2.4 애그리거트 입도

• 애그리거트는 작으면 작을수록 좋다.
  • 애그리거트 업데이트가 잘게 나눠져 있으면 그만큼 동시 처리 가능한 요청 개수가 는다.
  • 확장성도 좋아진다.
  • 같은 애그리거트를 업데이트 하다 충돌할 가능성도 줄기에 UX 면에서도 좋다.
• 하지만 애그리거트가 곧 트랜잭션 범위이기에 어떤 업데이트의 원자성을 위해 크게 잡아야할 수도 있다.
  • 소비자를 루트 엔티티로하고 주문 애그리거트를 소비자 애그리거트 일부로 하는 방법도 있다.
  • Consumer 애그리거트 루트를 통해 소비자-주문을 원자적으로 업데이트하거나 여러 주문을 원자적으로 업데이트할 수도 있다.
  • 하지만 애그리거트가 크면 서비스가 비대해지고 MSA 분해에 걸림돌이 되는 것이 문제

5.2.5 비즈니스 로직 설계: 애그리거트

• (마이크로)서비스 비즈니스 로직은 대부분 애그리거트로 구성된다.
  • 나머지는 도메인 서비스 및 사가에 위치
• 사가는 로컬 트랜잭션을 오케스트레이션하여 데이터 일관성 유지
• 인바운드 어댑터는 비즈니스 로직의 진입점인 서비스를 호출
• 서비스는 리포지터리로 애그리거트를 조회하거나 저장
  • 아웃바운드 어댑터로 구현

5.3 도메인 이벤트 발행

• 도메인 이벤트
  • DDD 맥락에서 이벤트는 애그리거트에 발생한 사건
  • ex) 주문 생성됨, 주문 취소됨
  • 애그리거트는 상태가 전이될 때마다 이에 관련된 컨슈머를 위해 이벤트를 발행한다.

5.3.1 변경 이벤트를 발행하는 이유

• 다른 구성원들이 애그리거트의 상태 변경을 궁금해하기에 도메인 이벤트는 유용하다.
• 도메인 이벤트가 유용한 경우
  • 코레오그래피 사가를 이용해 데이터 일관성을 유지할 때
  • 레플리카를 둔 서비스에 소스 데이터의 변경을 감지
  • 웹훅이나 메시지 브로커를 통해 비즈니스 프로세스의 다음 단계를 진행하도록 다른 애플리케이션에 알림
  • 사용자 브라우저에 웹 소켓 메시지를 보내거나 일래스틱서치 같은 텍스트 DB를 업데이트하기 위해
  • 사용자에게 알림을 전달할 때
  • 애플리케이션이 제대로 작동하고 있는지 도메인 이벤트를 모니터링
  • 사용자 행동을 모델링하기 위해 이벤트를 분석

5.3.2 도메인 이벤트란 무엇인가?

• 도메인 이벤트는 과거 분사형 동사로 명명한 클래스
  • ex) OrderCreated
  • 도메인 이벤트에는 이벤트 ID, 타임 스탬프 같은 메타데이터가 존재한다.
• 이벤트 객체를 감싼 엔벨로프 객체 (envelope object)
  • 메타데이터를 보관할 수 있다.

  • 애그리거트 ID가 이벤트의 프로퍼티가 아닌 엔벨로프의 일부일 수 있다.

    // 자신을 구현한 클래스가 도메인 이벤트임을 알리는 마커 인터페이스
    interface DomainEvent {}
        
    // 주문 애그리거트 이벤트임을 알리는 마커 인터페이스 
    interface OrderDomainEvent extends DomainEvent{}
        
    // 주문 생성 도메인 이벤트
    class OrderCreatedEvent implements OrderDomainEvent {}
        
    // 이벤트 객체 및 메타데이터를 조회하는 메서드가 존재
    interface DomainEventEvelop<T extends DomainEvent> {
        String getAggregateId();
        Message getMessage();
        String getAggregateType();
        String getEventId();
        
        T getEvent();
    }
    

5.3.3 이벤트 강화

• 이벤트 강화 (event enrichment) 기법
  • 이벤트 컨슈머가 필요한 정보를 위해 애그리거트를 조회하는 것은 오버헤드를 유발
  • 때문에 이벤트에 필요한 정보를 담아 이벤트를 강화하는 기법
  • 컨슈머를 단순화한다는 이점이 존재
• 이벤트 강화 기법을 쓰면 컨슈머를 단순화하는 이점이 있지만 이벤트 클래스 안전성은 떨어진다.
  • 컨슈머 요건이 바뀌면 이벤트 클래스도 변경해야 하기 때문
  • 모든 컨슈머를 만족시킬 수도 없다.

5.3.4 도메인 이벤트 식별

• 이벤트 스토밍
  • 복잡한 도메인을 이해하기 위해 이벤트 중심으로 워크숍을 진행하는 것
  • 도메인 전문가들이 모여 화이트보드나 포스트잇을 붙이며 진행
• 이벤트 스토밍 단계
  1. 이벤트 브레인스토밍
     1. 도메인 이벤트를 쥐어 짜내기
     2. 오렌지색 메모지 사용
  2. 이벤트 트리거 식별
     1. 이벤트를 일으키는 트리거를 식별
     2. 사용자 액션: 파란색
     3. 외부 시스템: 자주색
     4. 기타 도메인 이벤트
     5. 시간 경과
  3. 애그리거트 식별
     1. 각 커맨드 소비 후 적절한 이벤트를 발생시키는 애그리거트를 식별해 노란색 메모지로 표시

5.3.5 도메인 이벤트 생성 및 발행

도메인 이벤트 생성

• 개념적으로 도메인 이벤트는 애그리거트가 발행한다.
• 애그리거트가 이벤트를 생성하는 작업과 이벤트를 발행하는 작업은 분리해야 한다.
  • 이벤트를 컨슈머에게 전달하기 위한 메시징 API를 애그리거트가 직접 호출하면 인프라 관심사와 비즈니스 로직이 뒤엉켜 버린다.

• 도메인에서 이벤트를 반환하고 서비스에서 발행하는 방법

    @RequiredArgsConstructor
    public class KitchenService {
      
        private final TicketRepository ticketRepository;
        private final TicketDomainEventPublisher domainEventPublisher;
      
        public void accept(long ticketId, LocalDateTime readyBy) {
            Ticket ticket = ticketRepository.findById(ticketId).orElseThrow(...);
            List<TicketDomainEvent> events = ticket.accept(readyBy);
            domainEventPublisher.publish(Ticket.class, orderId, events);
        }
    }
  

  • Ticket.accept() 메서드가 이벤트를 반환하고 서비스에서 발행

• 애그리거트 루트의 필드에 이벤트를 쌓고 서비스가 가져다 발행하는 방법

    public class Ticket extends AbstractAggregateRoot {
        public void accept(LocalDateTime readyBy) {
            ...
            registerEvent(new TicketAcceptedEvent(readyBy));
        }
    }
  

  • registerEvent()는 AbstractAggregateRoot에 정의된 메서드
  • 서비스는 AbstractAggregateRoot.domainEvents() 호출해서 이벤트를 가져와 발행할 수 있다.

도메인 이벤트를 확실하게 발행하는 방법

• 도메인 이벤트를 확실히 전달하기 위해선 트랜잭셔널 메시징을 사용해야 한다.
  • 이벤추에이트 트램 프레임워크에 이런 메커니즘이 구현되어 있다.
• AbstractAggregateDomainEventPublisher

  • 타입 안전한 도메인 이벤트 발행용 인터페이스를 제공하는 추상/제네릭 클래스

    public abstract class AbstractAggregateDomainEventPublisher<A, E extends DomainEvent> {
    ...
    }
    

  • 애그리거트 타입(A)과 이벤트 마커 인터페이스 타입(E)를 정의
  • 이 클래스를 통해 KitchenService가 Ticket 애그리거트의 이벤트 마커 인터페이스인 TicketDomainEvent만 발행해야 한다는 제약을 구현할 수 있다.

5.3.6 도메인 이벤트 소비

• 도메인 이벤트는 결국 카프카 같은 메시지 브로커에 발행된다.
• 이벤추에이트 트램 프레임워크의 DomainDispatcher 같은 고수준 API를 사용할 수 있다.
• KitchenServiceEventConsumer
  • 음식점 서비스가 발행하는 이벤트를 구독하는 컨슈머

  • 주방 서비스의 데이터 레플리카를 항상 최신 상태로 유지

    @RequiredArgsConstructor
    public class KitchenServiceEventConsumer {
        private final private KitchenService kitchenService;
        
        public DomainEventHandlers domainEventHandlers() { // 이벤트와 이벤트 핸들러를 매핑
            return DomainEventHandlersBuilder
                .forAggregateType("net.chrisrichardson.ftgo.restaurantservice.Restaruant")
                .onEvent(RestaruantMenuRevised.class, this::reviseMenu)
                .build();
        }
        
        public void reviseMenu(DomainEventEnvelop<RestaruantMenuRevised> de) { // 로직 처리
            long id = Long.parseLong(de.getAggregateId());
            restaurantMenu revisedMenu = de.getEvent().getRevisedMenu();
            kitchenService.reviseMenu(id, reviseMenu);
        }
    }