아키텍처 리뷰 / 캠프장님 회의록
===

###### tags: `20220104`, `아키텍쳐 리뷰`

---
- 일시 : 2021.01.04 10:30 ~ 11:40
- 참석자: 계동원 캠프장님, LEMONADE(김완기, 이강호, 홍석기)
---

1차 리뷰 : 고민이 많이 담기고 / 진지하게 임하는게 보였다. 우리가! - 여승환 이사님께서 말씀하셨다.

### Backend

#### DB 스키마

- 데이터 타입이 빠져있다!!
- size -> shoe_size로 명확하게, 단순한 이름은 지양하자.
- name -> userName으로.

- User에서 수정해야할거!
- 개인적으로 ) is_admin, is_deleted … 굳이? 왜용?
- 이메일 인증은 어디있어요? 아쉽다… 이메일 인증, 권한, 유저가 disabled가 되어있는지 상태. -> status를 하나 주고 / 0(처음), 1(이메일 인증 됬을떄), 슈퍼유저 (99) , admin이다 (9) 이렇게… 숫자로 유저 상태를 판단.
- is_married… 이런 정보가 더 추가될 수 있지 않을까요? 예를 들어 결혼기념일?! 즉, 늘어날 수 있는 데이터니까, profile로 mysql로 관리하자. json형태로 프로필 하나로. +) 상태 메세지도 있을 수도 있자너!
- 언제 패스워드 수정했는지, updated_at or accessed_at (logined_at) … 이런 시간 개념이 있었어야 한다!
- region 까지 있었어야 한다. _ language code / 도 있는거가 좋고… (milestone3) / UTC 시간??
- index가 아니라, idx. uid가 없으니까 id로 가져가도 되겠다.

- Product 리뷰
- 상관관계가 너무 복잡하다. JSON으로 바꾸면 괜찮지 않을까? -> 길어져도 괜찮아요? 네 괜찮아요! / 데이터를 하나로 관리하는게 좋아요. product, product img 를 분리하진 말아라.
- meta … 도 분리 안해도 되지 않을까요? product안에 넣자!
- tanslated_name이 아니라 json으로 ? -> 일반 json으로 넣는것이 좋을것이다! // 잘 모르겠다 이 내용은.
- color는? -> deep learning을 위해서 … 상품의 색상.
- style_code … 스트릿은 (1) / 럭셔리 (2) / 캐주얼 (3) /
- 태그가 있으면 좋지 않을까?
- 20대에게 인기가 많은!

- buying, selling 리뷰
- 너무 같다! status를 통해 나눌 필요가 없어질 수 있지 않니?
- 음.. 나누는게 나을 것 같긴해욥. / 실제로는 똑같지 않을것 같긴해요.
- 판매데이터, 구매데이터를 같이 있으면 속도측면에서 느리지 않을가요? -> 그거는 괜찮아요!! 거래 양이 많지 않을테니까.. 아마 속도는 괜찮을거에요.
- buying, selling이 다를 수 있는게, 추가될 수 있는 필드들이 있을 수 있을것 같다! 그런걸 고려해서 따로 만들어라.
- created_at, updated_at가 붙어있어라.
- product_id 가 맨위로 올려라! 그 스키마 필드 안에서.
- date가 아니라 다른 단어를 쓰는것이 좋을 것 같다!

- join을 줄여주는게 좋다. // ? // 게시판 댓글에 보면 … id만 나오잖아 -> 이름을 display name으로? 넣어놔라. // 사실 어떤 문제에서도 퍼포먼스적인 문제는 없을것이다.

- wish, option도 id가 있었으면 좋겠다.
- 모든 데이터 테이블은 id가 필요하다고 생각해라. 언제든지 쓰일 수 있다.

#### Architecture

- 몽고디비 / mysql라고 쓰지말고 / user db 뭐 어쩌구 디비 이렇게 써라.
- firebase가 뭐할 거냐. 아 푸쉬니? -> 한눈에 보여야한다…
- 화살표 선도 수정!
- 레디스가 뭘 할거냐 ! -> token을 관리할건지 적어놔라.
- 글씨 크기, 및 폰트 bold를 좀 바꾸는게 좋을 것 같다. (product server 쪽 맨밑)
- 거래정보? -> 기간별 시세가 정보량이 좀 많다… stateCode가 필요할 것 같다.
- status 정도는 CONSTANT로 관리해라! 따로 빼지 말구.
- 서버간의 통신은 사실 쉽다. // 서버간의 데이터가 동기화가 중요하다. -> 같은 계열 내에서의 동기화가 중요하다.
- 카푸카? 뭐야 그건 또 그게 도움이 될지는 … 공부해야한다.

### Frontend
- atomic design pattern 이 뭔지, 한줄 요약이 있거나, 따로 페이지 넣어서.
- contextAPI를 통해서 뭘 관리할건지.
- SWR, NEXTjs, Storybook 에 대한 부가 설명이 필요하다.
- SWR이 어떤 거고, 장점이 뭔지.
- Nextjs를 통해서 얻을 수 있는 장점?
- Storybook 링크 타는거 x -> 동영상으로 발표 자료 내부에 첨부.
- 화살표 색상 바꾸기.
- 백엔드 부분 채워넣어라. (강호님께 이미지? 받기)

### IOS

- MVVM 패턴이 어떻게 적용됐는지 그림 외에도 위치를 넣으면 좋을듯.
- 역할에 따른 Layer을 구분해주자
- Gateway API 위치 수정
- 가급적 같은 역할을 하는(ex. 프로토콜)의 경우, 화살표 형태 통일
- Repository Pattern을 적용할 경우, 도입 이유을 명시하기