항해+ 백엔드 코드 8주차 회고 : Event 기반 Transaction

항해 20만원 할인 추천인코드: NYFKU8 

 

이번 주 과제는 기존에 구현된 비즈니스 로직을 이벤트 기반 아키텍처로 리팩토링하는 것이었습니다. 단순히 하나의 트랜잭션으로 처리하던 복잡한 로직을 이벤트 발행과 구독 모델로 분리하면서, 트랜잭션 범위를 축소하고 관심사를 분리하였습니다.

 

 

애플리케이션 이벤트를 통한 관심사 분리

Event 기반 흐름 제어

• Event 를 발행 및 구독하는 모델링을 통해 코드의 강한 결합을 분리함
• Event 에 의해 본인의 관심사만 수행하도록 하여 비즈니스 로직간의 의존을 느슨하게 함

활용 방안

• 비대해진 트랜잭션 내의 각 작업을 작은 단위의 트랜잭션으로 분리할 수 있음
• 특정 작업이 완료되었을 때, 후속 작업이 이벤트에 의해 trigger 되도록 구성함으로써 과도하게 많은 비즈니스 로직을 알고 있을 필요 없음
• 외부 API 호출 및 부가 로직의 실패나 지연이 주요 비즈니스 로직(트랜잭션)에 영향을 주지 않도록 구성할 수 있음

class OrderPaymentService {
	Transaction {
		fun 주문_결제() {
			유저_포인트_차감();
			결제_정보_저장();
			주문_상태_변경();
			
			결제_완료_이벤트_발행();
		}
	}
}


class OrderPaymentEventListener {

	TransactionEventListener(AFTER_COMMIT) {
		Async {
		  // Notify Service
			fun 주문_정보_전달(결제_완료_이벤트)
		}
	}
	
	TransactionEventListener(AFTER_COMMIT) {
		Async {
			fun 결제_완료_알림톡_발송(결제_완료_이벤트)
		}
	}
}

• OrderPaymentService에서 핵심 로직의 가독성이 훨씬 좋아졌습니다.
• 결제 완료에 대한 부가 로직에 대한 관심사를 분리했습니다.

 

Implementation

이벤트를 활용해서 단순히 부가 로직을 분리할 뿐만 아니라, 여러 도메인이 결합하여 구성된 핵심 로직을 각 도메인별로 관심사와 트랜잭션을 분리하도록 구성할 수도 있습니다.

주의할 점

• 각 작업의 논리적 의존이나 관계를 잘 파악해야 함
  • Service A 로직이 수행된 이후에 이벤트를 발행하여 Service B와 Service C가 각각 로직을 수행함
  • 만약 Service B 로직을 수행한 이후에 Service C 로직을 수행해야 한다면?
• 만약 이벤트에 의해 파생된 작업이 실패하였을 때, 원본 작업 또한 실패 처리를 해야 한다면 이를 위한 처리가 필요함 ( keyword : 보상 트랜잭션, SAGA 패턴 )
• 이벤트에 의해 각 작업이 영향을 주고 있는지, 혹은 이벤트가 발생하면 안되는 상황에서 이벤트가 발행되고 있지는 않은지 등

 

이번주 과제 내용

STEP 15 Application Event

• 실시간 주문정보(이커머스) & 예약정보(콘서트)를 데이터 플랫폼에 전송(mock API 호출)하는 요구사항을 이벤트를 활용하여 트랜잭션과 관심사를 분리하여 서비스를 개선합니다.

STEP 16 Transaction Diagnosis

• 서비스의 확장에 따라 어플리케이션 서버와 DB를 도메인별로 분리했을때, 트랜잭션 처리의 한계와 대응 방안에 대한 설계 문서 제출

 

• Step15 PR
• Step16 PR

Step15 by seuthootDev · Pull Request #16 · seuthootDev/hanghae-plus-backend

 

Step16 by seuthootDev · Pull Request #17 · seuthootDev/hanghae-plus-backend

 

 

항해 20만원 할인 추천인코드: NYFKU8