이벤트 소싱 + 헥사곤 레일스: 생존 가이드

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

개발 툴

대상자

- 대상: 중급~고급 레벨의 소프트웨어 개발자, 복잡한 시스템을 설계/유지보수하는 개발자

- 난이도: 이벤트 소싱과 헥사곤 아키텍처를 이해한 개발자에게 유용

핵심 요약

• 이벤트 소싱은 시스템의 모든 상태 변경을 불변의 로그로 저장하여 디버깅과 유지보수를 용이하게 한다.
• 헥사곤 아키텍처는 프레임워크 독립적인 비즈니스 로직을 구현하여 결합도를 낮추고 확장성을 높인다.
• 이벤트 데이터만 포함하는 업캐스터와 단일 책임 원칙을 적용한 구독자로 스키마 진화와 결합도 해소를 실현한다.

섹션별 세부 요약

1. 이벤트 소싱과 헥사곤 아키텍처의 핵심 원칙

• 이벤트 소싱은 시스템의 불변 상태 변경 기록을 통해 디버깅 가능성을 제공한다.
• 헥사곤 아키텍처는 비즈니스 로직과 프레임워크 간 결합도를 제거하여 확장성을 강화한다.
• 잘못된 구현 시 이벤트 스파게티와 리플레이 헬 같은 문제를 유발할 수 있다.

2. 코드 예시: 비즈니스 로직과 이벤트 분리

• Core:: 패키지에서 ActiveRecord 콜백을 제거하고 비즈니스 규칙을 구현한다.
• 이벤트는 데이터만 포함하는 Events::OrderPlaced와 같은 형식으로 생성해야 한다.
• OrderProjection은 이벤트를 기반으로 필요한 상태를 재구성한다 (예: 레일스 모델, API 등).

3. 흔한 실수와 해결책

• 이벤트에 ActiveRecord 모델을 의존하는 경우 결합도가 높아진다.

→ 데이터만 포함하는 이벤트로 수정해야 한다.

• 이벤트 스키마 변경 시 기존 프로젝션에 영향을 줄 수 있다.

→ 업캐스터(Upcaster)를 사용해 스키마를 점진적으로 업데이트 한다.

• 하나의 핸들러가 이메일, 분석, 재고 관리 등 다중 작업을 처리하면 단일 책임 원칙 위반.

→ 단일 책임 구독자(Single-responsibility subscriber)로 분리한다.

4. 사용 시나리오 및 제한 사항

• 단순 CRUD 앱이나 짧은 개발 기간에서는 과도한 복잡성을 유발할 수 있다.
• 이벤트 저장소는 모니터링이 필요하며, DevOps 지원이 부족할 수 있다.
• 디버깅 가능성과 장기적인 유연성이 더 중요할 때 사용한다.

결론

• 작은 규모부터 시작하여, 예를 들어 결제 같은 핵심 워크플로우에 이벤트 소싱을 적용한다.
• ActiveRecord는 쿼리에만 사용하고, 점진적으로 비즈니스 로직을 프로젝션으로 이전한다.

> 핵심 팁: 이벤트 소싱과 헥사곤 아키텍처는 장기적인 유연성과 디버깅 가능성이 중요한 시스템에서 효과적이다.