설계 및 API 특강

설계 및 API 특강

해당 특강은 DDD Start! 등의 저서를 작성한 최범균 강사님께서 강의해주셨다

---

설계란

그렇다면 설계 시 고려해야할 것은?

구조, 데이터 모델, 알고리즘, 인터페이스

소프트웨어에서 실제로 사용할 모델, 물리적인 저장소에서 사용할 모델 -> 분리해서 사용할수도

 

설계시 고려할 사항으로는 데이터의 규모와 요구하는 응답 시간이 있다.

인터페이스

시스템 간 데이터를 주고 받는 연동방식, 규약 정의

프론트 백엔드간(Http), 백엔드간 API(TCP, GRP 등)이 잇다.

요구사항

설계는 요구사항이 무엇이냐에 따라 바뀐다. 즉, 요구사항은 설계의 출발점이라고 할 수 있다.

구성 요소 크기

3개의 그림의 차이(ListComp)

구성요소를 정말 작게 할수도 있고 아닐수도 다양함

• 그렇다면 기준으로 삼을 만한 규칙이 있을까? -> 여러 역할을 하지 않도록 나눌 필요가 있다.

적절하게 나눈 예시

그래서 가장 기억해야할 것은? 적절하게 나눠야 한다.

ER 모델 (Entity Relation)

데이터베이스에 저장할 데이터의 구조 설계

• 주요 구성 요소
  • 개체, 속성, 관계, 카디널리티
• 결과물
  • ERD

요구사항 -> ER

• 요구사항에 출현하는 명사를 주로 검토
• 속성을 담을 엔티티 검토
• 속성 도출, PK 검토
• 하나의 속성으로 묶이는 대상 찾기
  • 구분, 종류, 상태
• 숨은 요구사항 찾기
  • 요구사항이 완벽하지 않기 때문에!
• 운영을 고려한 속성
  • 어떤 서비스를 만들고 끝이 아닌 운영하는 과정에서 필요한 서비스를 찾아야 함

요구사항 예시

상태에 대한 속성, 준비상태와 같이 특정 상태일 때 어떤 속성으로 명칭지을 것인지도 고민해보자

그런 후 속성값에 무엇이 있을지에 대해서도 생각

varchar(10) -> 

열거타입

 

설계 시 고민사항

요구사항이 최대 N개의 형태로 되어있을때 -> 한 테이블에 넣을지, 별도 테이블에 넣을지

숨겨진 요구사항에 대해서도 파악해야 한다.

각각에 대해 꼼꼼하게 따져보기

시간도 꼼꼼하게

서비스 운영 중에 클레임이 들어온다면 낭패

따라서 명확하게 정하기

취소 했다면

데이터를 삭제할지 취소 표기할지(보통은 취소 했다는 표식을 남김)

기준 규칙의 위치

DB에 넣으면? 값만 바꾸면 됨 ->  장 : 운영중 용이, 하지만 단: 값을 조회하는 코드가 늘어남 

 어플리케이션-> 장 : 코드 분석에 용이, 단:  변경 시 배포해야함(DB방식 대비 시간이 조금 더 걸림)

---

정답은 없다. 회사의 구성에 따라 달라짐

값 바뀔일없음 -> 어플리케이션

쿼리 중심으로 이루어진 회사 -> DB

 



생성일시, 생성자, 수정자, 수정일시는 저장하는 것이 좋다!

인덱스

운영중에서 사용되는 것 -> 목록, 검색 기능, 정렬 등

쿼리를 남발하다보면 데이터 개수가 많아질수록 속도가 느려지기 때문에 인덱스에 대해 고려해야함

 

하지만, 미래를 과하게 대비하지 말자...!!

타입

속성에 맞는 타입을 사용 

• 날짜 -> DATE,
• CHAR 사용시 주의 -> 가변적이면 공백문자 붙음 -> 값 비교시 문제가 될수도
• 파일 -> 대부분 경로를 저장. 강사님은 이것을 선호 -> 백업 등 복구 등에도 좋고 성능상에도 유리
  • 하지만 이미지 직접 저장하기도 함 성능은 느릴 수 있지만 데이터 안정성이 높다는 장점
• ENUM 기존 값의 개수에 변동이 있다면?
  • 단 : 값의 개수가 변경될 경우 서비스를 중단하고 점검해야할 수도
  • 때문에 값이 바뀔 가능성이 있다면 VARCHAR 사용하는 것이 위의 것들에 영향이 적다

 

어떤 컨텐츠에 대해 좋아요 처리를 한건지.(여러 컨텐츠에 대한 좋아요를 한 테이블에서 처리)

API 명세

API 종류는 2개로 나눌 수 있다.

조회용 API, 변경용 API

강사님의 팁

강제 X 경험상 추천

이름, 휴대폰 -> 서버에 존재하는 데이터

서버에 존재하는 데이터. 참가 신청하려는 사용자의 ID. 내부적으로 DB 조회 후에 3자에게 제공하는 것이 좋음

준비 상태의 작업만 시작할 수 있다 -> 프론트에 버튼이 있다는 것 

startable 이라는 속성으로 제공할때 프론트는 코드를 변경하지 않고(true false로 제공하니까) 서버만 startble의 조건을 바꾸면 됌

백엔드보다 프론트 배포가 더 부담이 된다는 것을 인지하자!

잘못된 구현 코드 관점 -> 승인 미승인으로 기능 의미가 없어져버림

즉 변경할 상태를 코드로 받는 게 아니라 기능을 API로 전달하는 것을 추천!!!!!

캐시 적립 API -> 화면 표시 여부를 Y -> API가 호출이 되면 무조건 적립이 되는 거임 -> 수정해야하는 

인증번호 노출 되버리니까 검사 서버에서 판단해야하고 인증번호 내려주면 안된다잉