2024년 4월 2주차 주간회고

 

E-commerce 시작

이번 주는 저번주에 ERD, 시퀀스 다이어그램 설계한 것을 바탕으로 본격적으로 e-commerce 서버 구축을 코드 작성을 통해 시작한 한 주였다.

기본적인 잔액 조회 및 충전, 상품 조회, 주문 및 결제 API를 구현하고 관련 비즈니스 로직의 유닛 테스트 및 통합 테스트를 작성하는 게 이번 주 과제의 주요 포인트였다.

기존에 설계하면서 생각하지 못했던 부분들이 코드를 작성하면서 생각이 나다 보니까 반복적으로 기존 설계 문서를 수정하는 상황이 발생했었다.
예를 들어 기존에는 주문 결제 과정을 두 개의 API로 분리하여 설계했던 것을 코드를 작성하다 보니 하나의 트랜잭션 단위에서 처리하도록 변경한 것과 상품에 대한 테이블 설계를 상품과 상품 재고 테이블로 나눴던 부분 같이 기존 설계했을 때 생각했던 것과 달라지는 부분이 많았다.

이러한 설계 역량에서 역량 차이가 난다고 생각하지만 아직 경험이 부족해서 어쩔 수 없는 부분이라 머리 박고 많이 배워야 되겠다는 생각을 한번 더 하게 되었다..

 

주문 및 결제

사실 이번 과제에서 가장 어려웠던 부분이 주문과 결제에 대한 부분이었다.
그래서 주문 결제를 진행하면서 고민했던 부분이나 어떻게 설계를 했었는지 한번 정리해 보면 좋을 것 같아 이전에 정리를 한번 했었다.
https://seungjjun.tistory.com/322

사실 아직까지도 내가 작성한 주문 결제 flow가 정답(?) 또는 일반적인 방법인지는 의구심이 드는데, 지금 와서 생각해 보면 과제의 핵심이 주문 결제 flow를 완벽하게 가져가는 것이 아니라 주문 결제에 대한 비즈니스 로직과 이에 대한 테스트 코드를 잘 작성하는 것이 더 중요하지 않았을까? 하는 생각이 든다.

Facade pattern

과제를 진행하면서 Facade pattern을 배우고 적용을 해보았는데 관련 내용을 글로 정리해 봤다.
https://seungjjun.tistory.com/323

Facade pattern을 적용하기 이전에는 Service를 재활용하기 위해 Controller에서 호출(Service 간 참조 시 순환 참조 문제 발생 가능하기 때문)하는 형태였기 때문에 특정 Controller는 의존하고 있는 Service가 많아지는 현상도 있었는데, 이렇게 되면 클라이언트가 특정 행위를 하기 위해 불필요하게 알아야 하는 게 많아지는 문제가 있다.
예를 들어 클라이언트는 주문을 하기 위해서는 단순히 주문에 대한 명령만 하면 되는데 주문을 하기 위해 상품을 가져오고, 결제를 하고 등등 여러 불필요한 행위를 알게 되는데, facade pattern을 적용하면 이러한 행위를 한 단계 추상화 계층을 둬서 클라이언트는 이러한 불필요한 작업들을 모르게 할 수 있다.

즉 클라이언트는 정말 주문이라는 명령만 하면 되고 그에 대한 응답만 받으면 되기 때문에 클라이언트 쪽이 아주 간단해지는 장점이 존재했다.

이러한 facade pattern 같이 평소에 불편함을 느끼던 문제들을 해결할 수 있는 디자인 패턴이나 아키텍처 설계 부분을 배울 수 있었고, 특히 이러한 패턴이나 아키텍처가 "왜" 필요한지에 대해 직접 느낄 수 있어 이해하는데 매우 도움이 되었다.

 

패키지 구조

그리고 패키지 구조에 대해서도 생각을 한번 하게 되었다.

이커머스 서버의 패키지 구조는 아래 사진과 같이 구성했다.

위와 같이 구성했을 때 생각되는 장점은 우선 루트 패키지 하위 구성으로는 api-domain(business)-storage 3-tier layer 관점에서 패키지를 나눴기 때문에 관리하기 용이하고 domain 패키지와 storage 패키지의 하위 패키지를 각 도메인별로 패키지를 나눠 도메인별로 컴포넌트를 모아 응집도가 높아진다는 장점이 있다고 생각이 되어 위 구조와 같이 설계를 했다.

하지만 위 구조 말고도 루트 패키지 하위를 각 도메인 별로 나누고 도메인 하위 패키지에 api, domain, service, repository처럼 도메인 중심으로 패키지를 구성하는 방법도 존재한다.

e.g.
root
  L  product
       L  api
       L  domain
       L  service
       L  repository
  L  order
  ...

사실 아직까지 위와 같은 패키지 구조를 직접 사용해 본 적은 없지만, 위와 같이 설계했을 때의 장점을 생각해 보면 도메인 별로 패키지를 나눠 관리하기 때문에 기존 구조보다 도메인에 대한 응집도가 훨씬 높아질 것 같고, 만일 팀별로 작업을 하는 도메인이 다를 경우 자기 자신이 맡은 도메인에 대한 코드만 이해해도 되기 때문에 팀적인 부분에서 효율성이 증가할 것이라고 생각이 된다.

사실 패키지 구조에 대한 부분은 정답이 없다고 생각하기 때문에 여러 패키지 구조를 직접 사용해 보면서 장, 단점을 몸소 느끼면서 본인이 좋다고 생각되는 패키지 구조를 선택하는 게 맞다고 생각이 된다. (선택에 대한 근거만 있으면..)


이번 주 과제는 생각보다 힘들었지만 생각보다 배워가는 내용이 많았고, 다행히 이번 과제까지 모두 pass를 받아 아직까지 나의 항해는 순항 중이다.

다음 주는 장바구니 관련 기능을 마무리하고 비즈니스 로직 작성에 좀 더 신경을 써보자.