2024. 2. 21. 17:55ㆍ카테고리 없음
1. 서비스 선정 배경
- 스프링부트 , 하이버네이트 학습이 목적 -> 여러 데이터를 다룰 수 있는 주제를 선정 (사용자 주소, 상품 카테고리 등)
- 참고자료가 많은 주제 선정
2 요구사항 정의서
- 일반 사용자, 등록 브랜드, 사이트 관리자별 요구사항 정의서 작성
구매 회원 페이지 -> 판매 회원 페이지 -> 관리용 페이지 순으로 페이지를 만들 예정이다.
각 단계에 따라 요구사항 정의서는 추후 수정할 예정이고 각 기능별로 github 이슈에 올려서 git-flow 방식으로 개발할 예정이다.
3. ERD, UML (ERD Cloud)
UML은 처음 요구사항 정의서를 참고하여 간단하게 설계했다. ERD를 설계할때는 누가 외래키를 가질 것인지, 또 더 많은 비지니스 로직을 수행하기위해 어떠한 테이블이 더필요한지 생각하며 UML를 참고하여 보완했다.
각 테이블의 세부적인 컬럼은 적지않고 관계에 치중해서 작성했다. 다만 각 테이블이 어떤 로직을 위해 필요한지 생각했고 아래에 이를 적었다.
또한 요구사항 정의서에는 없지만 적립금, 쿠폰, 개별 환불, 멤버쉽 기능을 추후 구현할 생각으로 환불 내역, 환불 상세, 적립금, 멤버쉽 , 회원 쿠폰 , 쿠폰 테이블을 추가했다.
작성 고려사항
기본적으로 비지니스 요구사항이 계속 달라질 수 있음을 감안하여 비식별 관계로 연관관계를 설정했다.
- 구매 회원, 카카오 회원, 일반회원 테이블
먼저 구매 회원같은 경우 로그인 방식에 따라 테이블이 필요한 정보가 다를것이라고 판단했다. 소셜 로그인같은 경우 토큰을 보관해야할 것이고 일반 회원같은 경우 따로 비밀번호가 있으니 슈퍼-서브 타입으로 작성했다.
- 회원 쿠폰 , 구매회원, 쿠폰
쿠폰 테이블에 쿠폰을 발행하고 회원 쿠폰 테이블에서 구매회원Id와 쿠폰id를 보관하여 다대다 관계를 풀어냈다.
- 멤버쉽, 구매회원
따로 테이블을 만들지 않는다면 멤버쉽같은 경우 적립률이나 할인률을 결정할텐데 회원의 멤버쉽이 달라질때 적립률이나 할인률도 같이 수정해야한다. (제3 정규화)
- 찜, 장바구니, 구매 회원(2번과 동일)
구매 회원 id와 상품 id를 외래키로 각각 추가한다. 구매 회원을 기준으로 조회하면 어떤 상품을 담았는지 확인할 수 있다.
- 구매 회원, 기본 배송지
구매 회원이 기본 배송지를 적으면 추후 주문 페이지에서 이를 조회하여 기본값으로 요청 칸에 넣는 로직을 위해 만들었다.
- 주문, 주문상품, 상품, 배송
배송같은 경우 주문에서 배송전 상태일때 수정할 여지가 많을것같아 테이블을 분리했다. 주문같은경우 핵심 도메인인데 부하가 많아지면 추후 주문이 마비가 됐을때 장애 전파가 매우 심할것같다고 판단했다. 그리고 컬럼을 추가하지는 않았지만 주문에 컬럼이 많아진다면 주문상세로 더 단순화 시킬 예정이다. 그렇게 분리한다면 세부정보를 나타내는 페이지와 단순정보를 나타내는 페이지를 분리시킬 수 있다.
- 주문상품, 배송현황, 판매회원
주문상품같은 경우 판매회원과 연결되어 판매회원으로 빠르게 조회할 수 있게 만들었다. 배송지같은 경우 주문에 따라 공통이지만
각 상품에 따라 책임지는 주체가 달라 주문 상품별로 배송 현황을 가지도록 설계했다. 배송 현황은 송장 번호를 판매자가 등록하면 이를 토대로 배송 조회를 하여 상태를 저장한다. 송장번호는 매 주문 상품마다 업데이트해야하므로 따로 빼서 주문 상품에 대한 부하를 줄였다.
- 주문 , 결제 , 결제 타입
주문별로 결제 내역을 기록한다. 또 결제타입을 구분해 추후 결제 타입별 적립금 , 할인률이 달라져도 수정이 용이하도록 설계했다.
- 주문, 환불내역, 환불상세, 주문 상품
주문 상품은 주문 시점 상품 가격을 저장하고 있다. 한 주문에 대해 환불이 있을수도, 있지 않을수도 있기때문에 환불내역 테이블을 1대1로 연관관계로 생성한다. 있다면 환불을 하면서 생기는 간단한 정보를 환불 내역에 적고 환불 상세는 어떠한 주문 상품에 대해 발생했는지. 환불 내역과 1대다 연관관계를 맺으며 개별 환불이 가능하도록 만든다.
- 주문 , 적립금
한번의 주문에 대해 적립금 사용과 적립 두가지 기능이 적립 내역에 변화를 줄 수 있다.
여기서 핵심은 적립금에 적립 금액과, 유효 금액, 만료일 컬럼을 추가하는 것이다.
적립된 경우 적급 금액과 유효 금액을 기록한다.
사용에 경우 회원에 따른 유효 금액의 합으로 사용 가능 여부를 산정하고 사용 가능한 경우 만료일이 가장 빠른 적립금부터 사용 금액이 0이 될때까지 유효금액을 수정한다.
- 상품, 상품 카테고리, 카테고리
하나의 상품은 여러 카테고리를 가질수있고 한 카테고리에는 여러 상품이 있다. 다대다 관계를 상품카테고리를 통해 해결한다.
그런데 카테고리같은 경우 상의 , 아우터 처럼 상위 카테고리와 하위 카테고리를 나뉠 수 있다.
이경우 A001002 같은 카테고리 코드를 만들어서 like를 이용하여 상위 카테고리에 포함되는 모든 하위 카테고리를 검색한다.
- 상품, 상품 정보, 상품이미지
상품정보 같은 경우 슈퍼-서브 타입으로 타입에 따라 다른 형식으로 데이터를 보관한다.
상품 이미지 같은 경우 한 상품에 여러장이 들어갈 수 있으니 따로 테이블을 분리했다.
- 상품, 주문 상품, 리뷰
1번의 주문으로 여러 상품을 담을 수 있다. 주문상품번호 1개마다 해당 상품의 리뷰를 달 수 있도록 리뷰와 주문 상품을 1대1로 매핑하고 리뷰와 상품은 일대다로 매핑한다.
여기서 중요한 점은 주문상품의 상품번호와 상품의 상품번호가 일치하는 경우에만 리뷰를 달 수 있어야한다.
- 문의사항, 상품 문의, 고객 문의, 주문 상품, 판매회원
문의사항이 운영 관련인지, 상품 관련인지 슈퍼-서브 타입으로 구분한다.
문의 사항에는 어떤 구매회원의 문의인지 확인한다.
상품 문의일 경우 구매 회원이 가진 주문상품에 있는 상품 번호와 동일한 상품 문의만 가능하다.
판매 회원은 여러 테이블을 걸쳐 상품 문의를 확인할 수 있겠지만 조회 성능 향상을 위해 상품 문의와도 관계를 맺는다.
- 문의사항 상세, 문의사항 , 문의사항 이미지
문의사항의 제목만 조회할 때가 있을 것이고 들어가서 상세 내용을 확인하는 경우가 있을 것이다. 이를 최적화하기 위해 테이블을 분리하여 지연로딩 한다.
4. 메뉴목록, IA 작성 (whimsical, draw.io)
각 페이지가 담아야할 기능 , 또 어떠한 버튼으로 분화되는지 나타냈다.
메인 페이지에서 분화되는 버튼들은 제품조회(진열된 상품을 클릭했을때의 페이지)를 제외하고 네비게이션 바로 관리할 것이다.
5. 와이어프레임 작성(figma)
메인페이지 , 로그인, 회원가입, 장바구니, 아이디/비밀번호 찾기 페이지의 와이어프레임을 작성했는데 이번 프로젝트는 api의 이해, 스프링 프레임워크 , jpa 학습이 목적이라 이 부분은 번거로워 생략하기로 했다.
하지만 이미 작성한 와이어 프레임까지 기능구현이 완료된다면 그 후의 페이지는 또 다시 작성할 것이다.