hee-commerce

🙇‍♀️ 프로젝트 개요

• hee-commerce는 티몬 과 같은 이커머스 서비스에서 운영될 수 있는 타임딜 서버로, 10분동안 TPS 3000를 감당할 수 있도록 구현 중입니다.
• 서버 시나리오를 구글 Docs에 상황을 구체화한 후 프로젝트를 시작하였고, 특히 “주문 API”에 집중하여 프로젝트를 진행했습니다.

🚀 기술 스택

• JAVA 17, SpringBoot 3, MyBatis 3.5, MySQL 8, Redis 7.0, Flyway 9.5.1, RestDocs, Docker

✨ 프로젝트하면서 중요시 했던 포인트

1. 다양하고 새로운 기술보다 문제에 집중해서 오버엔지니어링 하지 않기

• 트랜잭션이 필요한 엔티티 구조을 영속성이 필요 없는 필드를 제거하고 새로운 클래스를 만들어서 트랜잭션 필요 없는 엔티티 구조로 변경(#81)
• 다중 서버 환경에서 재고 차감과 관련된 동시성 이슈 문제를 분산락이 아닌 딜 상품과 재고 분리형 저장 구조와 재고 사후 검증 단계 도입으로 해결(wiki)

2. 테스트 코드 작성

• RestDocs를 이용하여 API 개발 시 TDD 원칙 적용 (초기 주문 완료 API, 주문 사전 저장 API, 주문 승인 API, 딜 상풍 목록 조회 API, 딜 상품 상세보기 API)
• 테스트 코드로 비즈니스 로직의 문서화를 위해 서비스 클래스가 아닌 도메인 모델에게 비즈니스 로직 책임 변경(#167)
• 가독성과 유지보수성을 고려해서 fixture 과 함수 활용해서 테스트 코드 리팩토링(#146)

3. 유지보수성을 고려한 코드

• 유지보수성을 고려해서 재고 증가/감소 및 재고 히스토리 저장 로직을 응집력 있게 묶어서 관리(#158)
• 유지보수성을 고려해서 RedisUtils 클래스를 만들어서 Redis의 key를 한 곳에서 응집력있게 관리 (#153)
• 유연한 코드를 위해 의존성 주입을 활용하여 인증 로직 구현(#171)
• int 대신 Integer 사용하여 동적쿼리를 단순한 정적 쿼리로 변경(#133, #144)

4. 고가용성을 고려한 시스템 설계 (진행 중)

• 시스템 설계 구조

5. 비동기로 진행되는 리뷰 상황에 대해 효율적인 소통을 위해 Github의 다양한 기능(이슈, 주석, 코멘트, PR)을 활용하여 문서화

• PR에 이 작업이 무엇인지, 왜 그렇게 했는지 등 맥락을 전달하기 위해 노력했습니다. (예시 : #72)

🤔 프로젝트하면서 했던 고민 포인트

1. 부분 주문 처리가 된 경우, 실제 사용자가 요청한 주문 수량과 실제 주문 처리 가능한 수량이 달라진다. 모두 DB에 저장되어 있어야 하는데, 어떻게 저장할까? (wiki)

2. 재고를 Redis에서 관리하고 있지만, Redis에 장애가 날 경우 등을 대비하여 백업용으로 MySQL에도 저장해야 한다. 어떻게 저장할까? (wiki)

3. 필터, 인터셉터, AOP 중 어떤 것으로 로그인 체크 기능을 구현할 것인가? (wiki)

🎈 DB 스키마

• DB 스키마

🎁 API 문서

• 주문 API 문서

🍿 주문 API WorkFlow