Optimizing the write side

write side 의 최적화 핵심은 command 와 event 의 처리량을 극대화하는 것이다.

일반적으로 write side 는 ui 에서 command 를 받거나 다른 바운디드 컨텍스트로부터 발생하는 integration 이벤트를 수신할 때 특정 로직이 수행된다.

messaging infrastructure 가 최소한의 지연으로 command 및 event message 를 제공하고, 도메인 모델의 처리량 및 속도 그리고 데이터소스와의 상호작용이 빠른지 확인해야 한다.

messaging infrastructure 를 사용하지 않고 inline 으로 command 를 전달할 수도 있다.
- 실패에 대한 탄력성 (resilience) 에 영향을 미칠 수 있다.
일부 command 를 병렬로 처리한다.
- 동시성 (concurrency) 에 대해 영향을 미칠 수 있다.

애그리거트를 로드할 때 전체 이벤트 스트림을 replay 하는 대신, 상태의 최신 스냅샷을 로드한 다음에 스냅샷을 찍은 후 발생된 이벤트만 replay 한다.

정기적으로 애그리거트를 위한 스냅샷을 만드는 매커니즘을 도입해야 한다.

그러나 일반적인 이벤트스토어 스키마의 단순함을 감한할 때, 애그리거트의 상태를 로드하는 것은 일반적으로 매우 빠르다.

스냅샷을 사용하는 것은 일반적으로 애그리거트에 매우 많은 수의 이벤트가 있을 때만 성능상 이점을 가져갈 수 있다.

Concurrency and aggregates

애그리거트와 command handler 의 간단한 구현은 애그리거트가 처리해야 하는 각 command 에 대해 애그리거트 인스턴스를 메모리에 로드할 것이다.

많은 수의 command 를 처리해야 하는 애그리거트의 경우, 모든 command 에 대해 다시 로드할 빌요가 없도록 애그리거트 인스턴스를 메모리에 캐시하기로 결정할 수 있다.

시스템에 메모리에 로드된 애그리거트의 단일 인스턴스만 있는 경우, 해당 애그리거트는 여러 글라이언트에서 전송되는 command 를 처리해야 할 수도 있다.

시스템이 큐를 통해 애그리거트 인스턴스에 command 를 전달하도록 순서를 보장하면 애그리거트가 command 를 순차적으로 처리하도록 할 수 있다.

또한 한 번에 하나의 command 만 CommandHandler 에 들어가기 때문에 애그리거트 스레드를 Thread Safe 하게 만들 필요도 없다.

command 의 처리량이 훨씬 더 높은 시나리오에서는 다른 프로세스에서 여러 애그리거트 인스턴스를 메모리에 로드해야 할 수도 있다.

여기서 동시성 문제를 처리하기 위해서는 이벤트 소싱과 versioning 을 사용해야 한다.

각 애그리거트 인스턴스에는 이벤트를 저장할 때마다 업데이트되는 버전이 있어야 한다.