[이벤트 기반 마이크로서비스] 이벤트 설계

이벤트 설계에 대한 안티 패턴

이벤트는 오직 진실만을 이야기해야한다

• 이벤트는 단순히 "뭔가 일어남"을 전하는 메시지가 아닌 그 이벤트가 발생한 동안의 모든일을 빠짐없이 기술하는 것 이다
  • 입력 데이터를 받아 만들어낸 비즈니스의 결과물

스트림당 이벤트 정의는 하나만 사용

• 이벤트는 하나의 의미만을 담아야 한다
• 종류가 다른 이벤트들을 섞어 넣으면 이벤트 실체와 스트림 정체성에 혼란을 줄 수 있다

가장 좁은 범위의 데이터 타입 사용

• 데이터 타입을 좁은 범위를 사용하면 타입 체크 기능, 직렬화 기능등을 아주 단순하게 사용 및 테스트할 수 있다
  • 문자열을 이용해 숫자 값을 저장
  • 정수를 불리언으로 사용 (0, 1)
  • 문자열을 통해 Enum 으로 사용 등

이벤트는 하나의 목적만 갖도록

• 보통 "비슷하지만 다른" 데이터를 처리하려고 이렇게 하는 경우가 많고 이벤트를 다목적으로 오해한 결과이다
• 결국 이벤트 스키마만 같을 뿐 전혀 다른 이벤트가 공존하기 때문에 나중에는 이벤트가 무슨 의미인지 짐작조차 할 수 없다
• 이벤트는 수많은 종류의 데이터를 기록하는 일반 이벤트가 아닌, 하나의 비즈니스 액션에 관한 것이어야 한다
• 다양한 타입 매개변수를 지닌 Generic 이벤트만 있어도 된다면 그건 경계 컨텍스트가 제대로 정의되어 있지 않다는 의미이다

이벤트를 시그널로 사용하지 말자

• 이런 이벤트는 어떤 결과의 단일 진실 공급원이 아닌 그냥 뭔가가 일어났음을 알릴 뿐이다
• 만약 이벤트를 처리하지만 그 안에는 실제 작업 결과가 없다고 가정해보자
• 이때 다른 사람이 이벤트를 제대로 소비하기 위해 실제로 완료된 작업 정보가 있는 곳을 찾아야 한다
• 이렇게 데이터 조각 하나에 진실 공급원이 2개 생기게 되면 일관성에 문제가 발생하게 된다