[이벤트 소싱과 마이크로서비스 아키텍처] CH.3 이벤트 소싱 I

이번 챕터를 읽으면서, 기존에 내가 작성하던 스타일의 모호한 개념들이 명확히 정리 되는 느낌이 들었다.

이런 개념을 명확히 인지하면서, 앞으로의 코드를 작성할 때면 kotlin 스타일의 패키지 정리에 좀 더 집중해야 되겠다는 생각도 들었다.

 

모든 내용을 정리하진 않을 것이며, 기존에 알고 있던 내용 이외에 새롭게 받아 들인 내용만 정리할 것이다!!

 

도메인 이벤트

변경의 단위를 비즈니스 처리 과정에서 발생한 결과로 정의

이벤트란 사용자가 무엇인가 처리하도록 "시스템"에 요청한 것임을 알 수 있는 힌트이면서 변경이 발생한 이유임을 알 수 있다.

 

이를 테면, PasswordChanged 라는 객체의 네이밍을 보면, 도메인에서 어떤 일이 일어났는지 즉시 이해가 가능하다.

 

public class QuantityChanged {
	private String eventId;
    private String productNo;
    private int quantity;
    private long time;
    
    private QuantityChanged() {
    	this.eventId = UUID.randomUUID().toString();
        this.time = System.currentTimeMillis();
    }
    
    public QuantityChanged(String productNo, int quantity) {
    	this();
        this.productNo = productNo;
        this.quantity = quantity;
    }

해당과 같은 도메인 이벤트가 있다면,

애그리거트에서는 아래와 같이 event 를 보관할 수 있다.

 

class Cart {

	private val cardId: String
    private val items: List<Item>
    
    private val events: List<Event>
    
    public Cart(cartId: String) {
    	// ...
        
        this.events = ArrayList<>()
    }
    
    fun changeQuantity(productNo: String, quantity: Int) {
    	// ...
        
        val event = QuantityChanged(productNo, quantity)
    	events.add(event)
    }

애그러거트는 위와 같이 변경에 대한 이벤트를 보관한다.

이벤트 객체는 아래와 같이 추상화가 가능하다.

 

abstract class Event {
	
    private val eventId: String
    private val time: Long
    private val cartId: String
    
    fun Event() {
    	this.event = UUID.randomUUID().toString()
        this.time = System.currentTimeMillis()
    }
    
    fun getPayload(): String = JsonUtil.toJson(this)
    
}

class QuantityChanged: Event { // ... }

 

 

커맨드와 이벤트

커맨드란

- 행위를 실행하는 방법

- 사이드 이펙트가 있는 작업

- 시스템 상태를 변경하는 의도를 가진 메시지 (현재 진행형이다.)

- 사용자 또는 시스템의 다른 부분에서 생성

 

이벤트란

- 이미 발생한 사실에 관한 설명

- 발생한 것으로 과거형으로 네이밍

- 이벤트는 시스템 내에서 발생한 것이다.

- 메소드가 반환한 것이 아닌, 명령을 실행한 결과이다.

 

이벤트 모델링을 시작하면, 시스템의 동작에 대해서 생각하게 된다.

커맨드와 이벤트를 통해 비즈니스 프로세스를 명확하고 쉽게 식별할 수 있다.

 

application service 로 전달 되는 객체인 request dto 를 command 라고 칭해도 되지 않을까?

외부로부터 요청 오는 요구 사항에 대해 행위를 실행하게 하는 주체이자 객체이지 않은가?

 

덧붙이자면, command, event postfix 를 붙이기 보단, 행위에 더 집중한 네이밍을 작성하도록 노력해보자.

내가 요새 service, repository, dto 대신 행위를 수행하는 객체 자체에 이름을 붙이려고 노력하는 이유이다.

 

커맨드는 자기 자신에 유효성 검사를 실행하게 해도 좋다고 한다.

 

이벤트 소싱에서는 커맨드와 이벤트를 처리하는 메소드를 각각 핸들러 라 칭한다.

도메인 이벤트로 도메인의 변경 이벤트를 쉽게 기록할 수 있다.

이벤트 소싱은 자연스레 애그리거트에 비즈니스 로직을 구현하는 효과가 있으며 독립적이면서 실용적인 단위 테스트를 가능케 한다.