숏컷 코드
text
한 결과를 여러 곳이 들어야 함
-> event
순서와 성공 여부가 중요함
-> direct call문법과 예시
이벤트는 방송형이고, 직접 호출은 협력형이다
같은 "함수 호출"처럼 보여도 성격이 다릅니다. 이벤트는 "이 일이 일어났다"를 방송하는 방식이고, 직접 호출은 "이 일을 지금 해 달라"는 협력 방식에 가깝습니다. 그래서 한 결과를 여러 시스템이 들어야 하면 이벤트가 맞고, 순서와 반환 결과가 중요하면 직접 호출이 더 읽기 쉽습니다.
text
직접 호출
OrderService -> PaymentService.Charge()
이벤트
PaymentCompleted 발행
-> Email
-> Analytics
-> Achievementevent-driven이 항상 더 유연한 것은 아니다
이벤트 구조는 결합을 줄이지만, 흐름 추적은 더 어려워질 수 있습니다. 따라서 "누가 들어도 되는 방송형 결과"에 쓰는 편이 맞습니다. 반대로 핵심 비즈니스 규칙과 순서 보장이 중요한 경로는 직접 호출이 더 안전합니다.
직접 호출이 단순한 경우를 억지로 event로 바꾸면 흐름만 흐려진다
결제 승인, 저장 성공 여부, 락 획득처럼 실패 처리와 반환값이 중요한 작업은 event보다 직접 호출이 적합합니다. 이걸 억지로 이벤트로 풀면 누가 성공을 보장하는지, 실패를 어디서 처리하는지 흐려집니다.
좋은 설계는 둘을 섞되 경계를 분명히 둔다
핵심 처리 경로는 직접 호출로 끝내고, 그 결과를 주변 시스템에 알릴 때만 이벤트를 쓰는 방식이 실전에서 가장 많습니다. 즉 command/query는 직접 호출, aftermath notification은 event로 두는 식입니다.
event와 direct call을 고를 때 핵심
| 상황 | 더 자연스러운 선택 |
|---|---|
| 한 결과를 여러 시스템이 들어야 할 때 | event |
| 순서, 성공 여부, 반환값이 중요할 때 | direct call |
| 호출 대상이 하나뿐이고 관계도 안정적일 때 | direct call |
| 나중에 반응자가 늘 수 있는 알림일 때 | event |
| 디버깅할 때 흐름 추적이 더 중요할 때 | direct call 우선 |
| 핵심 처리 후 부가 반응을 흩뿌릴 때 | direct call + event 혼합 |
특이 케이스와 주의할 점
흔한 실패는 event-driven을 "더 좋은 구조"라고 일반화하는 것입니다. 핵심 경로까지 이벤트로만 풀면 성공 기준과 실패 처리 위치가 흐려집니다. 유연성과 추적 가능성의 균형을 같이 봐야 합니다.
text
실패 예시
- 결제 처리 자체를 PaymentRequested 이벤트 하나로만 연결
결과
- 누가 실제 결제를 보장하는지 흐려짐
- 실패 처리와 재시도 위치도 모호해짐