2.4 이벤트 소싱: 이벤트 스토밍 다이어그램 기반으로 구현하기 #1540
Description
2.4 이벤트 소싱: 이벤트 스토밍 다이어그램 기반으로 구현하기
이벤트 주도 아키텍처를 이용하면 이벤트 스토밍으로 발견한 도메인 이벤트, 명령, 정책 등을 실제 소프트웨어 설계와 구현에 적용할 수 있습니다.
이벤트 주도 아키텍처는 소프트웨어 구현을 돕는 강력한 도구로써 시스템 설계에 새로운 관점을 제공합니다.
기존 방법론에서 간과하기 쉬운 이벤트 흐름과 시스템 상태 변화에 집중함으로써 훨씬 유연하고 투명한 시스템을 구축할 수 있습니다.
또한 업무 로직과 시스템에 대한 상태 관리를 더 직관적으로 이해하고 통합할 수 있습니다.
2.4.1 이벤트 스토밍 다이어그램 사례
책 이미지 참고 필요
2.4.2 이벤트를 전제로 하지 않는 구현
전통적인 구현
책 코드 참고 필요
전통적인 구현의 문제점
개인의 능력에 따라 달라지는 해석
첫 번째 문제점은 사람마다 자신의 역량에 따라 다이어그램을 다른 방식으로 해석한다는 점입니다.
이러한 부분은 팀원이 바뀔 때 팀 전체의 구현 능력에도 영향을 미치며 나아가 프로젝트에도 부정적인 영향을 미칠 수 있습니다.
다이어그램과 구현의 괴리
개발자의 상이한 해석이 쌓이다 보면 시간이 지날수록 최초의 다이어그램과 실제 구현 코드가 점점 달라진다는 점입니다.
이러한 불일치는 시스템의 유지보수를 어렵게 만들고, 향후 확장성이나 변경에 대한 유연성을 떨어뜨립니다.
또한 개발팀과 도메인 전문가를 비롯한 이해관계자 간의 의사소통 문제도 유발하여 프로젝트의 원활한 진행을 저해할 수도 있습니다.
2.4.3 이벤트 중심의 구현
이벤트 소싱이란
이벤트 소싱은 이벤트 주도 아키텍처와 밀접한 관련이 있는 패턴입니다.
이벤트 소싱은 애플리케이션의 상태 변화를 기록하는 방식이며, 이벤트와 관련된 모든 변경 사항과 동작이 기록됩니다.
그래서 애플리케이션의 과거 이벤트를 기반으로 현재 상태를 재현할 수 있습니다.
애플리케이션의 모든 상태 변화를 투명하게 추적할 수 있으며, 오류 발생 시 디버깅이나 비즈니스 프로세스 등을 감시하기 쉬워집니다.
이렇게 저장된 이벤트 로그는 시스템의 상태를 재현할 수 있으므로 다양한 요구에 유연하게 대응할 수도 있습니다.
프레임워크를 활용한 구현
프레임워크는 이벤트 지속화, 이벤트 스트림 관리, 상태 변경, 업무 로직 실행 등 이벤트 소싱 특유의 복잡한 작업을 간소화합니다.
또한 이벤트 소싱의 다양한 패턴과 모범 사례를 제공하여 초기의 실수를 줄이는 데도 도움이 됩니다.
이를 통해 개발자는 업무 로직 자체의 구현에만 집중할 수 있게 되고, 이에 따라 빠르고 신속하게 개발할 수 있으며 시스템의 신뢰성 향상도 기대할 수 있습니다.
2.4.4 이벤트 소싱을 통한 구현
액터의 명령 처리(결제 접수)
외부 시스템이 접수한 사용자 결제를 처리하기 위한 부분입니다.
명령을 전송하기
여기에서는 액터가 사용자에게 받은 결제를 처리하기 위해 API를 실행합니다.
이는 HTTP 요청을 수락하는 컨트롤러에 해당됩니다.
명령을 받아서 이벤트 발생하기
...
외부 시스템의 처리(신용 카드 결제)
결제 방식이 신용 카드일 때 결제 웹 API를 처리하는 과정입니다.
이벤트를 트리거로 하여 다음 명령을 전달하기
이벤트 트리거로 처리하는 경우에는 해당 이벤트를 인수로 하는 메서드를 정의하고 @eventhandler로 코드의 의미를 명확하게 수식합니다.
외부 시스템에서 이벤트가 발생한다
외부 시스템과의 아키텍처 차이로, 자사 시스템의 로직이 영향을 받는 것을 방지하기 위해 부패 방지 계층을 이용합니다.
덧붙여 HTTP 통신에서 발생할 수 있는 통신 오류 등을 줄이고자 지수 백오프(Exponential Backoff)를 통해 재시도하는 방식으로 처리하고 있습니다.
애그리게이트가 명령을 수락하는 처리(결제 완료)
결제 정책을 처리하는 것은 외부 시스템으로, 여기서는 애그리게이트 인스턴스를 읽어 들이는 부분에 주목합니다.
이벤트 소싱에서는 최신 상태를 알 수 없기 때문에 상태 정보를 얻으려면 인스턴스를 생성한 후 해당 인스턴스와 관련된 이벤트를 불러오는 방식을 사용합니다.
리드 모델을 생성하는 프로세스(송금 의뢰하기 이벤트에서 송금 대기 목록을 작성한다)
이벤트를 받아 리드 모델 생성하기
이벤트를 받아 리드 모델을 생성하는 객체는 프로젝션(projection) 등으로 불립니다.
리드 모델을 생성하고 있는 코드 자체는 객체와 RDB 데이터를 매핑하기 위한 일반적인 O/R 매퍼(Object-relational Mapper)인 Spring Data JPA를 활용한 것입니다.
이 리드 모델은 배치 프로그램이 참조하며, 후속 처리의 API를 실행할 때 파라미터에 이용합니다.
리드 모델이 주는 혜택
시스템의 업데이트를 명령으로 처리하고, 데이터를 읽어 내는 것은 쿼리로 합니다.
이처럼 명령의 결과 데이터(여기서는 이벤트)에서 쿼리용 데이터를 만드는 방법으로 명령 쿼리 책임 분리(CQRS, Command Query Responsibility Segregation) 패턴이 많이 알려져 있습니다.
특히 이번과 같이 이벤트 소싱(ES, Event Sourcing)을 활용하고 있는 경우는 CQRS+ES라고 부를 수 있습니다.
CQRS+ES를 활용하면 시스템을 쉽게 구축할 수 있습니다.
명령을 내리는 시스템 측면에서는 RDB와의 데이터 처리 방식의 차이에 따른 격차를 고려하지 않아도 되기 때문입니다.
2.4.5 이벤트 스토밍과 이벤트 소싱
이벤트 스토밍 다이어그램과 비교
이벤트 소싱 코드를 보면 이벤트 스토밍 다이어그램의 포스트잇과 클래스 정의가 일치한다는 것을 알 수 있습니다.
포스트잇은 클래스로 정의할 수 있으며, 그것들의 연결은 다이어그램의 패턴으로 결정됩니다.
구체적으로 조건 분기 등을 구현하기 위한 로직에 미세한 차이는 있지만, 일정한 패턴화가 가능합니다.
이 패턴화로 다이어그램과 코드를 일치시킬 수 있습니다.
다이어그램과 코드의 일치 효과
다이어그램과 코드가 일치되면 개발자는 다이어그램 패턴에 따라 코드를 작성할 수 있게 됩니다.
예를 들어 다른 도메인의 개발자가 오더라도 다이어그램과 코드가 일치하기 때문에 곧바로 프로그래밍을 시작할 수 있습니다.
또한 코드를 변경하려고 할 때도 어디까지 영향을 미치는지 확인하는 것이 더 쉬워집니다.
이벤트 스토밍 다이어그램으로 변경하고자 하는 대상에서 화살표가 이동하는 방향만 봐도 되기 때문입니다.
그러기 위해서는 시스템을 변경할 때마다 다이어그램도 업데이트해야 합니다.
다이어그램을 잘 만들어야 나머지 팀원들은 이것을 믿고 코딩에만 집중할 수 있게 됩니다.
페어 프로그래밍(pair programming)이나 몹 프로그래밍(mob programming)을 해야 하는 상황이라면 더욱 이해하기 쉬울 것입니다.
피드백의 동기
다이어그램이 없으면 코드를 작성할 수 없다는 것은 강한 피드백의 동기가 되기도 합니다.
코드를 작성하다 보면 다이어그램에 문제가 있다는 것을 알고, 이것을 변경해야 하는 상황이 생길 수 있습니다.
이벤트 스토밍 다이어그램은 도메인 전문가나 팀의 합의로 만들어 낸 것으로, 변경할 때는 전문가의 의견이 필요할 수도 있습니다.
이때 얻은 피드백에 따라 더 나은 개선 방법을 발견할 수도 있습니다.
2.4.6 인프라스트럭처 구성
Axon 프레임워크에는 전용 서버 시스템인 Axon Server가 있습니다.
이것은 마이크로서비스 스케일링이나 메시지 브로커, 저널 검색 기능 등을 제공합니다.
아울러 Axon 프레임워크는 JDBC(Java DataBase Connectivity)로 RDB를 이용할 수 있습니다.
메시지 브로커로서 아파치 카프카를 이용할 수 있는 플러그인도 제공합니다.