주문 결제를 이벤트 기반 아키텍처로 구축하기이 글에서는 주문 결제 시스템을 이벤트 기반 아키텍처로 전환하면서 겪었던 문제와 그 과정을 공유하고자 합니다.  현재 이커머스 프로젝트의 주문 결제 시스템은 한 트랜잭션 내에서 동기 처리 방식으로 처리하고 있습니다.  현재 OrderUseCase를 간단히 살펴보면사용자 조회 -> 상품 조회 -> 상품 재고 조회 -> 주문 -> 결제 -> 재고 차감 순으로 주문 결제 시스템이 이루어져 있습니다. 그럼 이 주문 결제 시스템을 이벤트 기반 아키텍처로 구축하면서 겪었던 문제와 과정을 정리해 보겠습니다. 이벤트 기반 아키텍처로 변경하는 이유결합도 감소현재 주문 결제 시스템은 상품 재고 관련 로직, 결제 로직이 주문 로직에 깊게 관여되어 도메인끼리 강한 결합을 갖고 있다는..

Facade Pattern을 사용하여 시스템 응집도와 재사용성을 어떻게 개선할 수 있을까? 이전 글에서 OrderService에서 의존하고 있는 컴포넌트가 너무 많아 응집도가 떨어지고 강결합이 발생하는 문제가 있었다고 언급을 했었습니다. 그래서 이번엔 facade pattern을 E-commerce 서비스에 적용하여 리팩터링 한 내용을 정리해보려고 합니다. 기존 OrderService 코드 public class OrderService { private final UserReader userReader; private final UserPointManager userPointManager; private final UserPointValidator userPointValidator; private fin..

주문 결제 트랜잭션 단위를 어떻게 가져가야 할까 이번에 이커머스 서비스를 만들면서 주문 결제 트랜잭션 단위를 어떻게 설계할 것인지에 대해 고민을 많이 하게 되었습니다. 우선 이 서비스에서 결제는 별도의 pg사를 연동하지 않고 user 테이블에서 point를 관리하여 이 point로 결제를 하는 서비스입니다. 주문 결제 트랜잭션을 분리하는 방안과 하나의 트랜잭션으로 가져가는 2가지 방안에 대해 어떤 방법이 더 적절(?)한 지 고민하고 생각했던 내용을 정리해보려고 합니다. 사실 "이 방법이 무조건 맞아!" 같은 정답이 없다는 건 머리로는 알지만 이런 선택을 해야 할 때는 누군가 정답을 줬으면 좋겠다는 마음이 있습니다. 아직까지는 트레이드 오프하는 게 쉽지 않은 것 같습니다.. 주문 결제 트랜잭션 분리 우선 ..