Table
Search
속성
주제
질문 또는 인지 이유
답변 완료 여부 또는 인지 여부
답변
프로젝트 설정
화면 설계서에 맞춰서 DB 설계 및 ERD 문서를 제작해야합니다.
- ERD 설계는 데이터 베이스 툴을 이용하여 제작하여도 되고, 별도의 툴을 이용하여 제작해도 됩니다. (이미지 가능)
DB 설계 이미지와 ERD 문서를 넣어주세요.
프로젝트 설정
Swagger 사용을 지향합니다.
하지만 API 문서에 필요한 항목(서버 접속 주소, API별 Request 값 형식 및 예시, 오류 코드 설명 및 예시)들이 빠지지 않는 선에서 구글 스프레드 시트 혹은 노션 등을 사용해도 됩니다.
API문서가 담긴 Swagger 링크 혹은 구글 스프레드 혹은 노션을 공유해주세요.
기본 Domain 구성 가이드
API 제작 시 모든 유효성 검사를 꼭 넣어줘야 합니다. 클라이언트에서 유효성 검사를 했으니 서버는 안 해도 된다는 마음 가짐은 절대 해서는 안됩니다.
Postman 혹은 Curl(명령어)과 같은 것을 이용하여 수동으로 API를 보내는 경우를 고려해서 모든 유효성 검사는 Skip하는 경우가 없어야 합니다.
어떤 식으로 Validation 관리할 것인가요?
if 문으로 정규화 처리
로그인 된 유저를 세션에 넣어 클라이언트에서 보내는 고유 id들 검증
기본 Domain 구성 가이드
서버에서 다양한 케이스로 에러가 발생했을때 서버가 중단되면 안 됩니다.
서버가 중단되지 않도록 try / catch 를 잘 감쌌는지 확인해야해요.
catch 가 발생했을 때 오류를 무시하면 안 됩니다. 적합한 에러 코드를 넣어서 return 해줘야 합니다.
기본 Domain 구성 가이드
게시물 작성 시 여러 테이블을 생성, 수정, 삭제 해야 한다면 try/catch 내에 Transaction 으로 감싸주고 성공의 경우 commit, 실패의 경우 rollback 을 해줘야합니다.
기본 Domain 구성 가이드
데이터베이스 Connection Pool 을 사용 할 경우, DB CRUD(생성,조회,수정,삭제) 가 끝날 경우, 두 가지 모두 connection.realese 를 놓치지 않아야 합니다..
기본 Domain 구성 가이드
데이터베이스 테이블 내에 “날짜” 의 경우 DATE Type 을 사용하지만, 날짜 뿐만 아니라 시,분,초 까지 필요한 경우 DATETIME Type 이 아니라 TIMESTAMP Type 을 사용해야 합니다.
앱에서 필요한 데이터는 날짜인가요? 시,분,초까지 필요한가요?
yyyy-MM-DD 으로 포맷 형식
기본 Domain 구성 가이드
API Response 내에 Success 와 Fail 상태를 파악하기 위해, HTTP Status 사용해서 Success 와 Fail 의 상태값을 알 수 있지만, 더 다양한 상황에 대응 할 수 있는 변수들이 필요합니다.
ex) API 통신은 성공했지만, 내부적 기획 로직에 따른 Success 와 Fail 을 구분해야하는 경우
더 다양한 상황에 대응하기 위해 어떤 변수들을 만들 예정인가요?
Response 관리하는 클래스 생성
기본 Domain 구성 가이드
API Response 내에 Success 와 Fail 상태를 파악하기 위해, message 변수가 필요합니다.
그런데 message 가 다국어를 지원해야하거나, 개발자에게만 message 를 보여주고 실제 유저에게는 다른 유저친화적 메시지를 보내야하는 경우에는 code 를 사용해야 합니다.
ex) API 실패인데, 유저가 값을 잘못 입력해서 실패한 경우
1. code =[ERROR_REQ_PARAM_EMAIL_REGEX], message = 이메일 형식 오류 와 같은 식으로 API Response 를 보냅니다.
2. 클라이언트에서는 message 는 개발자만 확인하고 code = [ERROR~REGEX] 을 ENUM 혹은 constant 에서 “이메일을 올바르게 입력해주세요.” 혹은 핸드폰의 언어상태에 따라 “Please enter the email correctly. ” 라는 문구를 가져와서 화면에 보여준다.
기본 Domain 구성 가이드
데이터 “삭제” 의 경우, 기획상으로 정말 데이터를 “삭제” 하는 경우를 제외하고는 테이블 내에 존재하는 “status”(=상태) 컬럼의 값을 활성화에서 삭제로 “수정” 해야합니다.
기본 Domain 구성 가이드
테이블 설계 시 데이터 자체의 “status”(=상태) 를 판단하는 컬럼과 기획적 상태를 판단하는 컬럼이 구분지어져야해요.
ex)
1. orderStatus(=주문상태) 컬럼과 status(=상태) 컬럼 2개를 만든다.
2. orderStatus 에서는 주문접수(입금대기), 결제완료(입금완료), 상품준비중, 배송준비중, 배송중, 배송완료, 리뷰작성대기중, 환불준비중, 환불완료 등을 관리한다.
3. status에서는 활성화, 삭제 를 관리한다.
기본 Domain 구성 가이드
데이터 삭제 API 의 HTTP Method 의 경우, 실제 데이터를 삭제하는 경우가 아니라면 DELETE Method 가 아니라 수정하는 작업이므로 PATCH Method (전체 데이터 NULL 로 변경이 필요시 PUT Method) 를 사용해야 합니다.
기본 Domain 구성 가이드
데이터 조회, 생성,수정,삭제는 API 용도에 따라 HTTP Method 를 적절히 매칭시켜야 합니다.
아래의 HTTP Method의 정의를 적어주세요.
GET, POST, PATCH, PUT, DELETE
GET : 리소스 조회
POST : 요청 데이터 처리, 주로 등록에 사용
PATCH : 리소스 부분 변경
PUT : 리소스를 대체, 해당 리소스가 없으면 생성
DELETE : 리소스 삭제
기본 Domain 구성 가이드
데이터베이스내에 데이터 생성 일시, 수정 일시를 담아두기위해 createdAt, updatedAt 을 TIMESTAMP Type 으로 만들어야 합니다.
updateAt 추가 예정
기본 Domain 구성 가이드
README.md를 보고 프로젝트가 어떤 구조로 설계 & 실행 해야하는지 알 수 있어야 합니다.
- 시스템 구성도 (그림 혹은 글)
- 폴더 구조 설명, 폴더별 기능 정의
(모든 파일을 나타낼 필요는 없습니다.
- 환경 설정 내역
EX) Dev, Stage, Production 환경에 따른 “API 호출 및 환경설정 코드 분기 처리” 여부와 설명
말보단 행동! Git 링크를 알려주세요.
기본 Domain 구성 가이드
- 변수, 파일, 폴더, 함수 등의 모든 이름들의 규칙을 통일해야 유지 보수가 용이합니다.
- Camel, Pascal 등의 케이스 규칙들이 있으니 프로젝트에 규칙을 세워보고 통일성을 유지해보세요.
- 변수명
- 폴더명
- 클래스명
- 엔티티명
- 이벤트 핸들러 플래그 변수|
- 함수명
네트워크 통신과 일반 함수를 구분 지을 필요가 있을지 고민해보고 적어주세요.
기본 Domain 구성 가이드
특별한 케이스가 아닌 경우, 주석을 작성해놓지 않아도 코드만 보고 이해할 수 있도록 짜야합니다.
여기서, 특별한 케이스란 코드를 파악하기 위해 “기획”을 알아야하는 부분을 뜻합니다. 그 외에는 코드만 보고 이해할 수 있어야합니다.
기본 Domain 구성 가이드
외부 라이브러리는 “기준 없이” 가져다 쓰면 안 됩니다. 해당 라이브러리의 신뢰성을 체크해서 가져와야 합니다.
아래의 질문을 정확하게 체크 후 라이브러리를 사용하세요.
- 타겟 라이브러리의 이슈가 꾸준히 해결되고 있는지
- 타겟 라이브러리의 관리자가 다른 오픈소스 라이브러리 또한 관리중인지
- 개인 오픈소스 관리자인지 기업 오픈소스 관리자인지에 따라 신뢰도가 달라지기도 해요.
- 타겟 라이브러리의 Star 숫자 혹은 Fork, Watch 숫자를 보고 대중적으로 쓰이고 있는게 맞는지
- 타겟 라이브러리의 라이센스가 프로젝트에서 사용하기에 적합한지
- 등...
User Domain구성 가이드
로그인/회원가입 API 를 생성 할 때, “자체 로그인” 인지 “소셜 로그인" 인지, 소셜 로그인이라면 카카오인지 “네이버, 구글, 애플인지 구분해서 유저를 관리 할 수 있도록 설계와 유효성 검사를 해야 합니다.
여러분의 프로젝트에서는 로그인을 어떤 것들을 구현하나요?
현재는 자체 로그인 (아이디와 비밀번호만)
추후 소셜로그인 도입 예정
User Domain구성 가이드
유저 개인 정보의 경우, 아래 사항들을 지킬 수 있도록 테이블 설계가 필요가 필요합니다.
1. 개인정보보호법에 따라 데이터베이스 저장 시 암호화를 해야 합니다.
2. 개인정보보호법에 따라 1년(혹은 보호법에 따라 다름)에 한번씩 유저에게 개인정보처리동의를 받아야 합니다.
Board Domain 구성 가이드
목록 조회 API는 pageIndex 와 size 파라미터를 꼭 정의해야합니다.
기획마다 다르지만 pageIndex 와 size 의 기본 값이 있는/없는 경우도 있습니다.
여러분의 프로젝트에서는 pageIndex와 size 기본 값이 있습니까?
없습니당
Board Domain 구성 가이드
게시물의 최대 텍스트는 몇 글자로 진행해야하는 지 확인이 필요합니다.
이와 같은 게시물 뿐만 아니라 모든 입력 받는 값에는 최소, 최대 글자 수의 유효성 검사가 필요하고 데이터 베이스 설계 시에도 반드시 고려가 되어야 합니다.
게시물의 첨부 파일 또한 고려를 해야합니다.
1. 이미지만 필요한지, 동영상까지 필요한지
2. 게시물의 첨부 파일은 1개만 존재하는 지, 여러개를 올릴 수 있는 지
고려된 것들을 이 페이지에 작성해서 정리해주세요.
Board Domain 구성 가이드
게시글 도메인 에서는 게시물 신고 기능이 필수적으로 필요합니다.
유저가 게시물을 신고했을 경우, 어떤 로직 하에 게시물의 visible/invisible의 상태를 바꿔줘야 하는지 확인이 필요합니다.
Admin Domain 구성 가이드
데이터를 조회(Read), 생성(Create), 수정(Update), 삭제(Delete) 할 수 있도록 API 를 구성해야 합니다.
Admin Domain 구성 가이드
데이터의 변화 히스토리를 알 수 있도록 로그시스템 설계가 필요합니다.
text File, RDBMS 내에 History 테이블 구축, NoSQL을 활용해서
구축, 로그용 3rd Party Library 활용 등 다양한 방법으로 로그시스템을 설계 할 수 있습니다.
Admin Domain 구성 가이드
관리자가 로그를 쉽게 조회 할 수 있도록 조회조건이 다양하게 필요합니다.
ㄴ 로그 조회 날짜 범위
- 시작날짜/시간, 종료날짜/시간
ㄴ 로그 조회 타입
- 로그 메시지의 Format 에 따라 대/중/소 카테고리가 있을 수 있습니다.