이벤트 기반 아키텍처, '수동 공격적 이벤트'를 조심하세요!

by DD
1개월 전
조회수 14

이벤트 기반 아키텍처(Event-Driven Architecture)에서 '수동 공격적 이벤트'는 명령을 이벤트로 위장하여 시스템의 가시성(Visibility)유지보수성(Maintainability)을 저해함

명령(Command)이벤트(Event)의 차이점을 명확히 이해하고, 단일 소비자를 갖는 이벤트는 명령으로 전환하여 동기적 통신(Synchronous Communication)을 최소화해야 함

상태(State)를 이벤트로 취급하는 '상태 집착(State Obsession)' 안티 패턴을 경계하고, 데이터 동기화(Data Synchronization)를 위한 문서(Document)의 역할을 이해해야 함

Example Mapping과 같은 모델링 기법을 활용하여 시스템 내 명확한 의도(Clear Intent)를 정의하고, 책임 분리를 통해 자율적인 컴포넌트(Autonomous Components)를 구축해야 함

수동 공격적 이벤트(Passive-Aggressive Events)의 문제점

게시물에서는 이벤트 기반 아키텍처(Event-Driven Architecture)에서 수동 공격적 이벤트(Passive-Aggressive Events)의 위험성을 지적한다. 이는 사실상 명령(Command)이지만, 이벤트 형태로 전달되어 시스템의 의도(Intent)를 모호하게 만든다. 특히, 단일 소비자를 갖는 이벤트는 명령으로 전환하여 명시적인 책임(Explicit Responsibility)을 부여해야 한다고 강조한다. 이러한 접근 방식은 시스템의 가독성(Readability)을 높이고, 문제 발생 시 디버깅(Debugging)을 용이하게 한다.

명령(Command)과 이벤트(Event)의 명확한 구분

게시물은 명령(Command)과 이벤트(Event)의 근본적인 차이점을 설명한다. 명령은 특정 작업을 수행하라는 의도(Intent)를 담고 있으며, 거부될 수 있다. 반면, 이벤트는 발생한 사실을 알리는 것이며, 무시될 수 있다. 이러한 차이점을 이해하고, 단일 소비자를 위한 이벤트는 명령으로 변경하여 동기적 통신(Synchronous Communication)을 최소화해야 한다. 이는 시스템의 결합도(Coupling)를 낮추는 데 기여한다.

상태 집착(State Obsession)과 문서(Document)의 역할

게시물은 상태(State)를 이벤트로 취급하는 상태 집착(State Obsession) 안티 패턴을 경계한다. 이는 데이터의 변경 사항을 이벤트로 전송하여, 소비자가 모든 상태 변화를 이해해야 하는 문제를 야기한다. 대신, 데이터 동기화(Data Synchronization)를 위해 문서(Document)를 활용하여, 상태 정보를 명확하게 전달해야 한다고 주장한다. 이를 통해 시스템의 유연성(Flexibility)을 확보하고, 불필요한 결합을 방지할 수 있다.

Example Mapping을 활용한 시스템 모델링

게시물은 Example Mapping과 같은 모델링 기법을 활용하여 시스템 내 명확한 의도(Clear Intent)를 정의하는 것을 권장한다. 이를 통해, 각 컴포넌트의 역할을 명확히 하고, 책임 분리를 통해 자율적인 컴포넌트(Autonomous Components)를 구축할 수 있다. 또한, 시스템의 가시성(Visibility)을 높여, 문제 발생 시 원인을 쉽게 파악하고 해결할 수 있도록 돕는다. 궁극적으로, 이는 시스템의 신뢰성(Reliability)을 향상시키는 데 기여한다.

Anti-patterns in event modelling - Passive Aggressive Events