도메인 주도 설계에서 Notification 이란 무엇인가?

목차
- 들어가며
- Notification이란?
- 왜 EventStore를 활용한 Notification이 필요해진걸까?
- 그림으로 이해해보는 Notification
- 조금 더 생각해보기

들어가며...

 토이 프로젝트에 참여하며 EventSouring에 대한 이야기를 이야기를 햇님과 이야기를 나눴습니다. 그러나, 이야기 중간중간에 "이벤트소싱과 Notification은 다른것이다." 라는 것을 끊임없이 말씀하셨고, 저는 이 둘을 비교할 수 있는 대상이라고 생각했습니다. 

그러나, 몇차례의 티키타가로 이 둘의 관계를 좀 더 면밀히 살펴보는 시간을 가졌습니다.

Notification이란?

 반 버논 책의 8장 도메인 이벤트 부분에 Notification에 대한 이야기가 있습니다.

 repository에서 애그리게잇 인스턴스를 가져올 땐 이벤트를 사용해서 재구성하는데, 이 때 재구성하기 위해서는 이벤트 소싱이 가장 중요한 요소입니다. 이렇게 저장된 이벤트 소싱은 재구성하기 위한 용도로 사용되지만, 

`특정 이벤트를 관심있어라 하는 주체`에게도 알려주어야 할 것 입니다. 이 때 우리가 주제로 다루고 있는 Notification 의 역할이 나옵니다.

  Notification은 이벤트 소싱에 저장된 일련의 이벤트들을 관심있는 애그리게잇 또는 관련 당사자에게 이벤트를 전달해줘서 핸들링합니다.

반버논 책에서는 `저장된 이벤트의 전달을 위한 아키텍처 스타일` 이라는 부주제로, 2가지 방식이 나옵니다.

- 레스트폴 리소스로서 알림 발행하기.
우리가 흔히 알고있는 발행-구독 패턴의 방식을 의미합니다.

- 미들웨어 메시징 제품의 토픽/익스체인지를 통해 메세지 발송
레빗MQ, 카프카와 같은 메세지큐를 활용한 방식의 메세지 발송을 의미합니다.

왜 EventStore를 활용한 Notification이 필요해진걸까?

 이 부분 또한 토이프로젝트에서 햇님들과 이야기를 나누며 해주셨던 이야기를 재구성했습니다.

만약 Notification이 없다면 우리는 어떻게 서비스가 발행한 이벤트에 관심있어라 하는 이해관계자에게 어떻게 메세지를 전달할까?

EventStore에 없는 방식

Recruit 라는 애그리게잇에서 Create Recruit 라는 커맨드가 발생했다 라면 Create Recruit 커멘드는

구현에 따라 다르겠지만, 위 그림과 같이 1. Recruit를 데이터베이스에 저장한다. 이후로 2. Recruit Created 이벤트가 발행될 것입니다.  그 다음에 발행된 이벤트는 직접적으로 3. 특정 이벤트에 관심있어하는 대상에게 메세지를 전달할 것입니다.

이 때 1 > 2 > 3 의 순서대로 트랜잭션이 진행된다고 가정하자. 그러면 중간에 2번이 fail될 경우 앞선 1번이 롤백이 되어야 할 것입니다.

또는 1 > 2 까지 와서 3번에서 fail이 될 경우 앞선 1,2 을 롤백해야 합니다.

이렇게 롤백을 보장하기가 힘들 뿐 아니라, 어디서 잘못됨을 디버깅하기 힘듭니다.

이런 문제 때문에 EventStore가 필요해지게 됩니다.

그림으로 이해해보는 Notification

event store를 활용한 메세지 전달

위와 달리 바로 직접적으로 이벤트에 관심있어라 하는 주체에게 이벤트를 전달하는 것이 아니라, Event Store에 이벤트를 저장합니다.

저장된 이벤트는 아래와 같은 그림을 보여줍니다.

eventstore를 활용한 데이터 메세지 전달

각각에 특정 이벤트 타입을 기다리는 Notification publisher 는 EventStore에 저장된 일련의 이벤트를 바라봅니다.

Scheduler와 Tracker

각각의 Notification publisher는 Tracker를 갖고 e1~e3까지는 Notifier에게 이벤트 전달, 그리고 Tracker는 3까지 전달되었다라는 것을 인지하고, e4는 다른 Notifiaction Publisher가 관심을 가진다면, 데이터를 전달해줍니다.

Scheduler는 이를 수행할 시간을 의미하며, Tracker에 의해 데이터를 곧바로 가져가는 것이 아닌 어느 정도 일정시간의 지연을 허용합니다.

일정시간의 지연은 각 도메인의 전문가가 결정하게 됩니다.

이렇게 DDD에서는 Notification이 이루어지는데, 코드상에서는 어떻게 일어날까? 이 부분에 대해서는 다음 포스팅에서 이루어지겠습니다.

 

조금 더 생각해보기

 만약 코드로 구현한다면 어디서 시작할 수 있을까?

앞서 이벤트 스토어를 쓰지 않는 방법이 나타내는 단점이 해결된 걸까? 

eventstore에는 어떤 데이터가 저장되어야 할까? 필요한 이벤트 body는 무엇일까?

이런 의문점은 아마도 직접 구현해보지 않기 때문에 발생하는게 아닐까 라는 생각이 든다. 어쩌면 분석후에는 위 그림이 달라질수도 있다. 그럼 또 추가해야지 : )