[이벤트 소싱과 마이크로서비스 아키텍처] CH.1 도메인 주도 설계

현재 다니고 있는 회사는 실 - 팀 구조로 나뉘어 있다.
나는 제품실 백엔드 엔지니어인데, 격주로 제품실 백엔드 회의를 진행한다.
 
현재 속해 있는 팀에서 프론트엔드 분들은 제품실 프론트엔드 개발자 분들끼리 테스트 관련 스터디를 하신다고 하여,
백엔드는 내가 한번 스터디를 제안하면 어떨까란 생각이 들었다!
회의 때, 스터디 주제와 시작에 대해서 소스를 던졌고, 나 포함 5명이서 제품실 백엔드 스터디를 진행하게 되었다.
 
현재 팀 & 실 별로 마이크로 서비스를 운영 중이므로,
첫 시작은 비교적 간결하고 익숙한 개념인 이벤트 소싱 활용한 마이크로 서비스 아키텍처에 대한 주제로 진행하게 되었다.
내가 진행하는 스터디만 뭐 거의 3개인데..  그래도 같이 하면 다 좋은 거지~~ㅎㅎ
이 스터디를 빠르게 마치고, 회사 소스에 적용할만한 테스트 관련 주제나 인프라 쪽으로 넘어가면 정말 재미있을 것 같다!
 
스터디 준비를 하며, 책을 읽었는데 이걸 개인 블로그에 기록하면 어떨까하여 매 Chapter 를 읽으며 내 경험과 생각을 정리할 계획!
 

첫 장, 도메인 주도 설계

취준, 신입 때 정말 많이 공부했던 개념인데, 이제서야 정리한다.
 
모델이라는 개념.
Grady Booch 는 "단순히 표현한 실제 세계" 라고 부른다고 한다.
모델은 관심사의 분리가 중요하다. 모델을 바라보는 관심사에 따라 모델의 정의가 달라지기도 한다.
우리는 개발자이므로, 기획자나 마케터등 "업무 담당자" 의 시선을 더 깊히 이해하려 노력하고 모델을 설계해야 한다.
 
서비스 레이어 패턴.
애플리케이션이 제공하는 사용 가능한 기능 집합
비즈니스 로직을 캡슐화 및 클라에게 영향을 주지 않되 변화를 수용하거나 성능 개선의 활동을 가능하게 한다.
이를 테면, Restful API 와 Socket 이나 grpc 등의 프로토콜을 요구하는 클라이언트를 충족시킬 수 있다.
 
도메인 모델 패턴.
요구사항이 다양해 짐에 따라, 유지보수성이 어려워진다.
도메인 모델 안에 이런 비즈니스를 분리한다.

public class CartService {

	public void addItem(String cartId, String ProductName, int quantity) {
    	int size = CartDao.selectItemSize(cartId);
        
        if (size >= 10) {
        	throw RuntimeException("..");
        }
    }
}
 
 // 너무나 유명한 패턴,, 그리고 오랜만이네 자바 코드,,

 
이러면 변경 요청에 유연하게 대응 가능하다. 유스케이스와 별개로~!
 
헥사고날 아키텍처
워낙 유명한 input, output adaptor 와 usecase 및 domain & business logic  그리고 infra layer
 
엔티티
개발자는 도메인 객체보다 데이터에 집중하는 경향이 있는데, 이런 경향성을 가진 개발자는 Entity 를 Table 로 간주하려 한다.
테이블과 관계 중심을 가지는 데이터 모델을 먼저 만들고, 테이블에 대응하는 클래스로 매핑하면 Entity 는 가장 기본적인 책임을 가진 Information Holder 역할을 가져 getter, setter 만 제공한다.
Entity 는 식별자가 존재하며, 생애주기를 가진다. 이를 테면, id 와 no 등이 있겠다.
이는 고유 번호로 UUID 로도 많이 사용하는 경우가 있다.
 
값 객체
Entity 와 다르게, 식별자가 필요 없는 객체이다.
이름에 걸맞게 Entity 를 수식하는 속성이라 생각하면 편하다.

public class Product {
    
    private String id;
    private String no;
    private String name;

    private Volume volume;
    
}

public class Volume {
    
    private int width;
    private int height;
    private int depth;
    
    public Volume(int width, int height, int depth) {
        this.width = width;
        this.height = height;
        this.depth = depth;
    }
}

 
이렇게 정의하면 어떨까? Volume 은 값 객체이므로 불변성을 띈다. 각 필드를 final 로 선언하는 것은 금상첨화일 것이다.
만약 Product 의 Volume 이 변경 되는 요구사항에 대응하려면 새로운(new) Volume 을 넣어줘야 한다.
값 객체에도 당연히 비즈니스를 캡슐화가 가능하다. 또성자로~!

public class Volume {

    private int width;
    private int height;
    private int depth;

    public Volume(int width, int height, int depth) {
        if(width * 1.5 >= depth) {
            throw new RuntimeException("Nagative!");
        }
        
        this.width = width;
        this.height = height;
        this.depth = depth;
    }
}

실용 주의~
 
인프라스트럭처 서비스
헥사고날에서 정의한 어댑터이다. 
DB, Network, API call, Mail sending, Event publishing 등의 기술적인 업무를 다룬다.
이 책임을 다른 서비스와 분리하지 못하면 순수하고 깨끗한 도메인 모델을 침범하게 될 것이다. 그로 인해 독립적인 테스트가 불가능!
 
애플리케이션 서비스
너무도 유명한 그 usecase.
트랜잭션 관리, 인프라스트럭처와의 상호작용을 포함한 비즈니스 usecase 의 흐름을 조정한다.
요약하자면 클라이언트의 요청부터 응답까지의 일련의 트랜잭션을 처리한다.
도메인 객체의 예외를 처리하는 것도 하나의 책임이다.
logging, metrics, monitoring 도 책임이라고 한다.
 
도메인 서비스
Eric Evans : Entity 에 부여하기 적합하지 않은 책임을 가지는 객체.
말 그대로 도메인을 위한 객체이므로, 순수 Pojo 로 구현되어야 한다.
이를 테면, Multi module 상 core 모듈에서 Spring 의존성이 빠져야 하는 이유이다.
 
중요한 비즈니스 프로세스를 수행하려거나,
어떤 컴포지션에서 다른 컴포지션으로 도메인 객체를 변환하거나,
하나 이상의 도메인 객체에서 요구하는 입력 값을 계산할 때!
 
추가로 도메인 서비스의 명칭은 Service 를 포함하기보다, 문제 영역에서 클래스 역할을 더 명확히 표현하는 이름이 낫다.

public class ProductCreationPolicy {
    
    public boolean isValid(Product product) {
        // 비즈니스 로직
        return true;
    }
}

 
이 외에도, 타입의 변환, 특정 도메인 객체를 사용하거나 DTO 로 변환하거나 반대의 경우일 때 사용한다.
 
애그리거트
도메인 객체들의 연관 관계에서 불변식(invariants)을 보장해야 하는 단위
여러개의 Entity, VO 로 구성 되며 포함할 수 있다. Aggregate 를 대표하는 Entity 는 Aggregate Root 라고도 부른다.
Aggregate 는 요구사항과 업무 지시자의 시각에 따라 달라지는 개념이므로, 명확한 텍스트의 정의 없이는 모호한 개념이라고도 부른다.
 
일례로 Cart, Item, Product 라는 Entity 가 있는데, Cart 가 Aggregate Root 가 되었을 때의 예시이다.

public class Cart {
    
    private String cartId;
    private List<Item> items;
    
    public Cart(String cartId) {
        this.cartId = cartId;
        this.items = new ArrayList<>();
    }
    
    public void addItem(Product product, int quantity) {
        Item newItem = new Item(product, quantity);
        this.items.add(newItem);
    }
    
    ///
    
    public boolean isEmpty() {
        return this.items.isEmpty();
    }
}

 
이렇게 Aggregate Root 를 정의하고, Usecase (application service) 에서는 Aggregate 를 통해 요구사항을 수행하는 일련의 과정만 나열하면 된다.
이렇게 설계한 Aggregate 는 단위 테스트에도 훨씬 용이하다. 책임이 분리 되어 있기 때문.
 
설계 규칙으로,
- 비즈니스 불변식을 애그리거트로 한정
- 작은 애그리거트로 설계
- 다른 애그리거트는 식별자로 참조
- 애그리거트간 변화는 결과적 일관성을 사용
 
추상화된 핵심
앞서 말하 여러 개념을 실무에 적용하기는 한계가 있다.
이런 빌딩 블록 외에 중요한 것 중 하나는 Abstract Core 이다.
 
Eric Evans 도메인 주도 설계 저서 중 이런 사례를 소개한다.
1. 선박에서 차량으로 직접 이동
2. 선박에서 야적장의 특정 위치로 이동
3. 야적장의 특정 위치에서 야적장의 다른 위치로 이동
4. 야적장의 특정 위치에서 차량으로 이동
 
Entity 는 컨테이너, 선박, 야적장, 차량, 크레인 등이 있다.
어떻게 설계할 것인가?

    public inteface MovingService {
        void move(Container container, Location from, Location to);
    }

 
정답은 없다. 하지만 모든 Entity 를 포함하기보다 Usecase 에서는 이렇게 간결하게 표현이 가능하다.
모델링을 쉽게 하며, 오퍼레이션도 단순해졌다.
 

---

 
도메인 주도 설계, 참 많이 공부한 개념이다. 간략하지만 직접 정리하는 건 처음이다.
다음 챕터는 객체지향 설계 원칙인데, 이건 알면서도 항상 적용하고, 특히 책임 있는 객체로 분리 및 설계가 쉽지 않다.
다음 장도 재밌게 읽어보자~!
 
출처 : http://www.acornpub.co.kr/book/microservices-eventsourcing  
그리고 나

이벤트 소싱과 마이크로서비스 아키텍처