조용한 개발 노트

Event-driven이 실패하는 가장 흔한 이유Event-driven Architecture를 도입했는데도 시스템이 여전히 복잡해지는 경우가 많다.그 원인을 따라가 보면 대부분 한 지점에서 멈춘다.Event, Message, Command를 구분하지 않았다이 세 개념을 섞는 순간, Event-driven 시스템은 동기 호출 시스템의 나쁜 점만 그대로 가져온다.Command는 무엇인가Command는 의도를 담은 요청이다.무엇을 해달라는 요구수신자가 정해져 있다성공 또는 실패를 기대한다Command의 핵심은 이것이다.이 작업을 수행해라즉, Command는 책임과 결과를 강제한다.동기 호출 구조는 대부분 Command 기반이다.Event는 무엇인가Event는 이미 일어난 사실이다.되돌릴 수 없다누가 소비할지..

13편에서는 트랜잭션과 비동기가“같은 실행 흐름을 공유할 수 없는 이유”를 ThreadLocal 기반 구조로 설명했습니다.그 논의의 끝에는 항상 다음 질문이 남습니다.“그럼 트랜잭션이 끝난 뒤에 무언가를 안전하게 실행하려면 어떻게 해야 할까?”이 질문에 대한 Spring의 공식적인 답이 바로트랜잭션 이벤트(Transaction Event)입니다.1. 트랜잭션 이벤트는 무엇을 해결하려고 등장했을까다음과 같은 요구는 실무에서 매우 흔합니다.주문이 성공적으로 저장된 뒤 알림 발송결제가 확정된 뒤 통계 집계회원 가입이 완료된 뒤 환영 메일 발송이 작업들의 공통점은:“트랜잭션이 성공했을 때만 실행돼야 한다”는 점입니다.하지만 단순히 메서드 끝에서 실행하면,아직 커밋되지 않았거나곧 롤백될 수도 있는 상태에서 외부 ..