8월 5일 (월)

Jump to bottom

김현욱 edited this page Aug 13, 2024 · 2 revisions

공동 목표 확립

문제 해결 경험을 쌓고 싶다.
- 성능적인 문제 해결:
  - 대용량 데이터 처리 이슈
  - 결제 동시성 이슈
  - 정산 정합성 이슈
  - 실시간 트래픽 이슈
- 아키텍처적인 문제 해결:
  - 유지보수가 용이한 설계 구조
공유하는 문화
- 발생할 수 있는 문제 상황에 대해 적극적으로 공유
- 스크럼을 통해 팀원 간 적극적인 피드백
기록하는 문화
- 개발 과정의 논의 사항, 이슈들을 문서로 남기기
- 살아있는 문서 관리

팀 컨벤션

코어 시간: 14시 ~ 17시
개발 과정:

처음부터 너무 완벽한 구현보단, 기본 기능을 단순한 형태로 진행하기

문제 상황을 같이 고민하고 발전시키는 구조로 진행하기
회의는 정규 시간에 진행하기
팀원 간의 솔직한 피드백 해주기, 단 감정이 상하는 워딩은 지양하기
문제 상황, 발생할 수 있을 것 같은 이슈들은 적극적으로 공유하기
문제 상황에 대해 다같이 고민하는 시간을 갖기
- 스크럼, 회고 때 활용
- 개발을 하면서 고민되는 부분들은 Discussion을 적극 활용

관리 문서

요구사항 정의서

누락된 요구사항은 깃 이슈에 요구사항 작성 및 요구사항 정의서에 갱신

스크럼 및 회의일지
문제 상황에 대한 논의는 깃 이슈와 댓글을 적극적으로 활용

문서 관리 방법

개발 관련 → 깃허브 Project
비개발 관련 (프로젝트 전반적인 내용) → 노션 (추후 논의)
(깃허브 위주로)

비즈니스 요구사항 도출

기술 스택

백엔드

Java 17
Spring-Boot 3.x.x
JPA

프론트엔드

뷰단 단순 랜더링은 타임리프
필요한 데이터는 rest API + JS

ERD 설계 (브레인 스토밍)

사용자

회원 : 판매자, 구매자 (Role Enum)→ 권한으로 구분 vs 테이블로 분리
- 판매자 / 구매자 기능이 완전히 분리되어 있으므로, 일단 테이블로 분리하도록 진행
- 예를들어 판매자는 사업자 정보를 등록할 수도 있어야하고, 정책사항, 매장 ID 등을 갖고있을 수 있다

전시

매장
음식
쿠폰
- 쿠폰 정책
회원 - 쿠폰 연결 테이블
- 발급 날짜
- 사용 여부
결제
- 회원 ID
- 주문 ID
- 결제 상태 (결제요청, 결제중, 결제완료, 결제취소)
  - 하나의 레코드에서 컬럼을 수정하는 방식으로 관리하지 않고, 각각을 레코드로 관리한다고 한다.
  - 결제는 민감한 정보이니, 로그성으로 남기는듯하다.
  - 고민할 부분: 이렇게 설계할 때 인덱싱 적용이 적절할까? (잦은 create)
- 생성,수정,삭제 날짜
- 중복 결제 요청을 어떻게 막아야할까
  - 애플리케이션 레벨에서 멱등성 키를 발급하여 관리한다
  - 테이블로 들어갈 값은 아님
주문
- 회원 ID
- 매장 ID
- 상품 ID
- 개수
- 고민해야할 부분: 동일 매장의 상품인지 validate

생각해봐야할 부분

옵션같은 비정규형 데이터를 RDB 정규화로 관리하는게 좋을까?

일반적으로 옵션은 사장 마음대로 커스터마이징할 수 있음
음식 옵션 선택 → RDB 정규화로 관리하기 까다로울 수 있겠다.
방법1. 옵션 컬럼 + JSON
방법2. NoSQL

쿠폰 선착순 문제

발급 기준으로 할 것인가?
결제 기준으로 할 것인가?

정산 테이블

일반적인 커머스 플랫폼은 모든 수익을 가져가고, 정산일에 정산한다고 함. → 정산 테이블

개인 미션, 팀 미션 일정 분배 (이번주만)

오전: 팀 프로젝트 얘기
오후: 개인 프로젝트
유동적
회의는 정규 시간에 진행