도메인 주도 설계 첫걸음 - 15장 이벤트 주도 아키텍처

범위

[Part 4] 다른 방법론 및 패턴과의 관계 - 15장: 이벤트 주도 아키텍처

개념 정리

• 이벤트 주도 아키텍처(Event-Driven Architecture): 시스템 컴포넌트가 이벤트 메시지를 교환하면서 비동기적으로 서로 커뮤니케이션하는 아키텍처 스타일. 서비스의 엔드포인트를 동기적으로 호출하는 대신 컴포넌트가 이벤트를 발생해서 시스템 도메인의 변경사항을 다른 시스템 요소에 알려준다. 해당 컴포넌트는 시스템에서 발생한 이벤트를 구독하고 그에 따라 반응 할 수 있다.
• 이벤트(Event): 이미 발생한 변화를 설명하는 메시지(과거).
• 커맨드(Command): 수행돼야 할 작업을 설명하는 메시지(명령, 미래).

책에서 기억하고 싶은 내용

이벤트 주도 아키텍처

이벤트

이벤트, 커맨드, 메시지

• 메시지에는 두 가지 유형이 있다.
  • 커맨드: 거부될 수 있다.
  • 이벤트: 취소할 수 없다.

구조

• 이벤트는 선택한 메시징 플랫폼을 사용하여 직렬화하고 전송할 수 있는 데이터 레코드다.
• 일반적인 이벤트 스키마에는 이벤트의 메타데이터와 페이로드(이벤트가 전달하는 정보)를 포함한다.
• 이벤트의 페이로드(payload)는 이벤트가 전달하는 정보를 설명할 뿐만 아니라, 이벤트의 유형도 정의한다.

이벤트 유형

• 이벤트 알림: 다른 컴포넌트가 반응할 비즈니스 도메인의 변경에 관한 메시지.
  • 보안: 수신자가 세부 정보를 얻기 위한 질의를 명시적으로 하도록 강제하는 것은 민감한 정보가 메시징 인프라를 통해 공유되는 것을 막고, 구독자가 데이터에 접근하기 위해 추가 권한이 필요하게 한다.
  • 동시성: 이벤트 기반 연동의 비동기적인 특성으로 인해 정보가 구독자에게 도착했을 때 이미 만료된 상태로 렌터링될 수 있다. 정보의 특성이 경쟁조선에 민감한 경우 명시적으로 질의하면 최신 상태를 얻을 수 있다.
• 이벤트를 통한 상태 전송(ECST: Event-Carried State Transfer) 메시지: 구독자에게 제공자의 내부 상태에 대한 변경사항을 알려준다. ECST 메시지는 두 가지 형태로 나타날 수 있다.
  • 수정된 엔티티의 상태에 대한 완전한 스냅숏
  • 수정된 필드만 ECST 메시지에 포함
• 도메인 이벤트: 도메인 이벤트는 이벤트 알림과 ECST 메시지 사이 어딘가에 있다.
  • 도메인 이벤트와 이벤트 알림의 관계
    • 공통점
      • 제공자의 비즈니스 도메인에서 발생한 변경사항을 설명한다.
    • 차이점
      • 도메인 이벤트에는 이벤트를 설명하는 모든 정보를 포함한다.
      • 모델링 의도가 다르다. 이벤트 알림은 다른 컴포넌트와의 연동을 돕기 위해 설계됐다. 반면 도메인 이벤트는 비즈니스 도메인을 모델링하고 설명하기 위한 것이다.
  • 도메인 이벤트와 이벤트를 통한 상태 전송의 관계
    • 도메인 이벤트에 호함된 데이터는 일반적인 ECST 메시지의 스키마와 개념적으로 다르다.
      • ECST 메시지는 제공자 데이터를 로컬 캐시로 보유하기에 충분한 정보를 제공한다.
      • 도메인 이벤트는 이러한 풍부한 모델을 노출해서는 안 된다.
    • 두 가지 유형의 메시지에 대한 모델링 의도가 다르다.
      • 도메인 이벤트에 포함된 데이터는 애그리게이트의 상태를 설명하기 휘한 것이 아니다. 대신 수명 주기 동안 발생한 비즈니스 이벤트를 설명한다.

이벤트 주도 연동 설계

분산된 커다란 진흙 덩어리

시간 결합

기능 결합

구현 결합

이벤트 주도 연동의 리팩터링

• 시스템에 이벤트를 맹목적으로 적용하면 시스템 결합도가 낮아지지도 회복력이 향상되지도 않는다.

이벤트 주도 설계 휴리스틱

• 최악의 상황을 가정하라
  • 이벤트 주도 시스템을 설계할 때 생각해봐야 하는 부분
    • 네트워크가 느렺ㄹ 것이다.
    • 가장 어렵거나 중요한 순간에 서버 장애가 발생한다.
    • 이벤트가 순서대로 도착하지 않는다.
    • 이벤트가 중복됩니다.
  • 이벤트가 항상 일관되게 전달되도록 하는 방법
    • 메시지를 안정적으로 발송하기 위해 아웃박스 패턴을 사용하자.
    • 메시지를 발송할 때 구독자가 메시지 중복을 제거하고 순서가 잘못된 메시지를 식별하고 재정렬할 수 있게 하라.
    • 보상 조치를 실행해야 하는 교차 바운디드 컨텍스트 프로세스를 조율할 때 사가 패턴과 프로세스 관리자 패턴을 활용하라.
• 퍼블릭 이벤트와 프라이빗 이벤트를 사용하라
  • 이벤트 소싱 애그리게이트에서 도메인 이벤트를 발송할 때 세부 정보를 노출하지 않도록 주의하라.
    • 이벤트를 바운디드 컨텍스트의 퍼블릭 인터페이스의 내재된 부분으로 취급하라.
    • 오픈 호스트 서비스 패턴을 구현할 때 이벤트가 바운디드 컨텍스트의 공표된 언어에 반영되게 하라.
  • 바운디드 컨텍스트의 퍼블릭 인터페이스를 설계할 때 다른 유형의 이벤트를 활용하라.
  • 외부 바운디드 컨텍스트와 통신을 위한 도메인 이벤트는 최소화하여 사용한다.
    • 전용 퍼블릭 도메인 이벤트를 설계하는 것을 고려하라.
• 일관성 요구사항을 평가하라
  • 컴포넌트가 궁극적으로 일관된 데이터를 처리할 수 있는 경우 이벤트를 통한 상태 전송 메시지를 사용한다.
  • 사용자가 제공자의 마지막으로 변경된 상태를 읽어야 하는 경우 제공자의 최신 상태를 가져오는 후속 질의와 함께 이벤트 알림 메시지를 발행한다.

결론

• 바운디드 컨텍스트 간 통신에 사용할 수 있는 세 가지 유형의 이벤트
  • 이벤트 알림: 중요한 일이 발생했지만 사용자가 제공자에게 추가 정보를 명시적으로 질의해야 하는 알림.
  • 이벤트를 통한 상태 전송: 메시지 기반 데이터 복제 메커니즘. 각 이벤트에는 제공자 데이터의 로컬 캐시를 유지 관리하는 데 사용할 수 있는 상태 스냅숏을 포함할 수 있다.
  • 도메인 이벤트: 제공자의 비즈니스 도메인 내에서 발생하는 이벤트를 설명하는 메시지
• 통합을 위한 올바른 유형의 이벤트를 선택하려면 바운디드 컨텍스트의 일관성 요구사항을 평가하고 구현 상세 노출에 주의하라.
• 퍼블릭/프라이빗 이벤트를 명시적으로 구분해서 설계하라.
• 스스템이 기술적인 문제와 시스템 중단에 직면하더라도 메시지를 전달하는지 확인하라.

연습문제