[WIL] Decoupling with event

🧠 이번 주에 새로 배운 것

• 이벤트를 통해, 하나의 작업에서 길어지는 동기 연산을 구분할 수 있다.
  • 불필요하게 긴 하나의 트랜잭션을 나누어 DB 리소스를 효율적으로 사용한다.
  • 도메인간의 결합도를 낮출 수 있다.
  • 핵심 로직과 부가 로직을 구분하여, 정합성을 맞춰야하는 것과 부가적인 비즈니스를 나누어 수행한다.
• ‘정말 하나의 트랜잭션으로 관리해야 하는지’, ‘분리한다면, 어떻게 분리하는게 좋을지’ 좋을지 고민할 수 있게 되었다.
• 스프링의 ApplicationEvent를 통해 어플리케이션 내부에서 이벤트 기반의 흐름을 제어할 수 있다.
  • TransactionalEventListener: 트랜잭션 특정 시점에 이벤트 처리
    • BEFORE_COMMIT, AFTER_COMMIT 등
  • EventListener: 이벤트 발행 시 즉시 처리

💭 이런 고민이 있었어요

• BEFORE_COMMIT은 결국 같은 트랜잭션 내에서 처리하는데 어떤 이점이 있을까?
  • 코드 레벨에서 도메인 간 결합을 분리할 수 있다.
  • 하지만, 명시적으로 파사드에서 작성하는 것이 더 안정적일 수 있다.
  • 책임 분리와 동시에 트랜잭션 원자성 유지가 목적이라면 사용할 수 있다.
    • ex) 로그 적재, Projection 데이터 업데이트
• 정말 부가로직으로서 각각 수행해야할까?
  • 결제 실패됨 → 쿠폰 복원 / 주문 상태 변경
    • 쿠폰 복원은 성공했는데, 주문 상태 변경이 실패한다면?
    • 이러한 경우, 두 부가 로직이 하나의 정합성으로 수행해야 함

💡 앞으로 실무에 써먹을 수 있을 것 같은 포인트

• 기존에 존재하는 하나의 긴 트랜잭션이 정말 하나의 트랜잭션으로 수행되어야 하는지 확인하자.
• 서비스의 흐름을 이벤트로 구분하여, 핵심 로직과 부가 로직을 나누어보자.
• 경계를 느슨하게 구성하고 동기/비동기를 나누어보자.

🤔 아쉬웠던 점 & 다음 주에 해보고 싶은 것

• 스프링의 ApplicationEvent는 JVM 내에서 동작
  • 시스템 외부로 전송해야한다면?
• 트랜잭셔널 아웃박스 패턴을 통해 DB 커밋과 메시지 발행의 일관성을 유지해보자.