E-commerce 마무리이번주는 E-commerce 서버 구축을 마무리하는 한 주로 아직 구현하지 못한 장바구니 관련 기능과 미비된 통합 테스트를 추가 작성하고, 주문 결제 시스템을 이벤트 기반 아키텍처 구조로 변경하는 작업을 했다.특히 기존 하나의 트랜잭션 단위의 주문 결제 시스템에서 이벤트 기반 아키텍처 구조로 변경하는데 많은 시간을 사용했다.이벤트 기반 아키텍처 구조로 변경했을 때의 이점과 왜 변경해야 하는지에 대한 고민과 독립적인 트랜잭션 구성 방법에 대한 많은 고민을 하고 관련해서 트러블 슈팅 글을 작성했다.https://seungjjun.tistory.com/328 [E-commerce] 주문 결제를 이벤트 기반 아키텍처로 구축하기주문 결제를 이벤트 기반 아키텍처로 구축하기 이 글에서는 주문..

프로젝트 선택E-commerce 서버 구축 프로젝트를 통해, 다양한 기술적 문제와 해결 방안을 경험할 수 있었다. 프로젝트의 선택 과정부터 구현까지, 트랜잭션 관리 방안, 이벤트 기반 아키텍처 구조로의 전환과 같은 문제들을 다루면서 평소에 경험할 수 없었던 내용들을 학습하면서 프로젝트를 진행했던 것 같다.처음에는 문서 작업부터 시작했는데, 프로젝트 초기 단계에서는 문서 작업의 어려움을 많이 느꼈다. 특히, 변경이 잦은 ERD와 API 명세의 수정이 반복되어 힘든 부분이 있었지만, 실제 개발을 진행하는 과정에서 초기 프로젝트 설계의 중요성과 필요성을 인식할 수 있었다. 트랜잭션 처리의 고민과 해결이번에 이커머스 서비스를 진행하면서 가장 시간을 많이 소비했던 부분이 주문 결제 시스템의 트랜잭션 처리 였다. ..

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

함수적 종속성(FD, Functional Dependency)함수적 종속성이란?함수적 종속성이란, 테이블 내에서 한 속성 X 값에 따라 다른 속성 Y의 값이 유일하게 결정이 될 때 “X가 Y를 함수적으로 결정한다.”라고 표현한다.반대로 "Y가 X에 함수적으로 종속된다."라고 표현할 수 있고 이는 테이블 내의 어떤 두 행에서 X의 값이 같다면 Y의 값도 반드시 같아야 한다는 것을 의미한다.  이러한 두 값 사이의 제약 관계를 functional dependency(FD)라고 부른다. 사용자 테이블을 예시                            ID                          이름                         주소                             1..

E-commerce 시작이번 주는 저번주에 ERD, 시퀀스 다이어그램 설계한 것을 바탕으로 본격적으로 e-commerce 서버 구축을 코드 작성을 통해 시작한 한 주였다.기본적인 잔액 조회 및 충전, 상품 조회, 주문 및 결제 API를 구현하고 관련 비즈니스 로직의 유닛 테스트 및 통합 테스트를 작성하는 게 이번 주 과제의 주요 포인트였다.기존에 설계하면서 생각하지 못했던 부분들이 코드를 작성하면서 생각이 나다 보니까 반복적으로 기존 설계 문서를 수정하는 상황이 발생했었다.예를 들어 기존에는 주문 결제 과정을 두 개의 API로 분리하여 설계했던 것을 코드를 작성하다 보니 하나의 트랜잭션 단위에서 처리하도록 변경한 것과 상품에 대한 테이블 설계를 상품과 상품 재고 테이블로 나눴던 부분 같이 기존 설계했을 ..

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