[Docs] API 명세서 설계

raminicano commented 3 weeks ago

🌳 이슈 설명

구매, 판매 주문 crud, 인증관리 crud를 구현한 api 명세서를 설계한다.

☀️ 해결 방식

https://melodious-scion-207.notion.site/103e571e640a80eea89ef0ab638802b8?v=898116ffa7ca47fab643afb3f258c6f4&pvs=4

[x] 구매 crud 작성
[x] 판매 crud 작성
[x] 인증 curd 작성

❄️ 주의할 점

유저의 권한 및 인증 여부를 고려한 적절한 에러를 리턴하고 에러 응답형식은 일관되게 유지해야한다. 어떤 부분에서 에러 및 특이사항을 고려해 로그를 기록할지 생각하자.

raminicano commented 3 weeks ago

deletedAt 소프트 딜리트 생각하기

raminicano commented 3 weeks ago

buy와 sell 두개에서 차이가 있을지?

raminicano commented 3 weeks ago

페이지네이션을 할때는 게시판처럼 모든 정보가 나타나는 것이 아닌 orderid, itemid, amount, status, orderdate 까지만 보여주기 그래서 단일주문조회는 orderId를 통해서 세부 정보를 확인할 수 있게 하기

raminicano commented 3 weeks ago

페이지네이션에서 디폴트 값은 date는 현재시간 기준 한달, limit은 10개, offset은 1

raminicano commented 3 weeks ago

읽을 수 있는 주문번호 고려 -> 원활한 cs업무를 위함. : 주문에 대한 대략적인 정보를 담고있어야함, 길이가 고정되어있어야함 야놀자, 쿠팡, 네이버페이, g마켓의 경우 숫자로만 구성된 주문번호를 생성했음 나는 판매주문이면 S로 시작하고 구매주문이면 B로 시작하도록 설정하려 했으나 어쳐피 테이블을 분리해 설계를 진행하므로 굳이 그럴 필요가 없다.

해당표를 통해 주문번호를 고려했을 때 우선 연월일(YYMMDD) + 영문자 3자리 (예 : 201011A1B) = 9자리로 하루당 27,000개의 주문을 처리할 수 있는 것으로 고려해봄. 해당링크 참고함.

주문번호 생성시 매번 db를 조회하지 않고 중복을 방지하면서도 규칙적이고 고유한 주문번호를 만들기 위한 방식으로 연월일 + 유저Id2글자, 시간기반 무작위 코드 3글자 yymmdd-xx-rrr 근데 무작위성에 따라 매우 낮은 확률이지만 랜덤코드 충돌이 발생될 수 있으니 해당 예외처리를 코드를 반환하고 끝내지 않고 에러를 핸들링하자.

raminicano commented 3 weeks ago

buy와 sell 두개에서 차이가 있을지?

구매와 판매는 다른 상태관리가 있다. 주문완료, 입금완료, 발송완료와 주문완료, 송금완료, 수령완료가 있다 dto설계시 유의하자.
price는 금의 시세이다. 고객이 금을 사고팔때 가격 차이는 플랫폼이 설정한 스프레드와 수수료에 따라 다르다. 일반적으로 구매시에는 시세보다 약간 높게 책정하고 판매시에는 시세보다 약간 낮게 책정한다. 해당 정보를 참고했을 때 부가가치세는 고려하지 않고 수수료만 고려했을 때 임의로 5%를 설정하였다. 소스코드단에서 구현한다.(시세의 경우 많이 변동되나 수수료의 경우 고정인 경우가 많아 데이터베이스에 따로 기록하기보단 하드코딩으로 진행한다.) 즉 현재 금의 시세가 1000원인 경우 살때는 1050원이고 팔때는 950원에 파는 것이다. 이 가격을 고려해 각기 다른 테이블에 price 값을 기입한다.

raminicano commented 3 weeks ago

주문 삭제에 있어서 추가적으로 ~~중일때는 삭제할 수 없다고 판단된다. 그러므로 dto에 수령중, 배송중을 추가한다.

raminicano / gold-trading