S.A를 작성해보자

stdio.han 2025. 2. 12. 20:45

2025. 2. 12. 20:45

이번에 새로 진행할 프로젝트는 '음식 주문 관리 플랫폼' 개발이다.

우리팀은 백엔드 개발팀으로서 프로젝트에 참여했다.(라고 상상하며 시작하자)

먼저 기획자가 알려준 개발 요구사항 명세서를 확인해보자.

개발 요구사항 명세서 - 배달 및 포장 음식 주문 관리 플랫폼
프로젝트 개요
- 주제: 배달 및 포장 음식 주문 관리 플랫폼 개발
- 목표: 광화문 근처에서 운영될 음식점들의 배달 및 포장 주문 관리, 결제, 그리고 주문 내역 관리 기능을 제공하는 플랫폼 개발
운영 지역
- 지역: 초기에는 광화문 근처로 한정하여 운영하며, 향후 확장을 고려한 지역 분류 시스템 설계 필요
- 향후 확장성: 지역별 필터링, 지역정보 수정 및 추가 등이 가능 하도록 고려
음식점 분류
- 카테고리: 다음과 같은 음식점 카테고리로 분류
  - 한식
  - 중식
  - 분식
  - 치킨
  - 피자
- 향후 확장성: 음식점 카테고리를 추가하거나 수정할 수 있도록 유연한 데이터 구조 설계 필요
결제 시스템
- 결제 방식: 카드 결제만 가능
- PG사 연동: PG사와의 결제 연동은 외주 개발로 진행하며, 결제 관련 내역만 플랫폼의 데이터베이스에 저장
- 결제 테이블: 결제 내역을 저장하기 위한 전용 테이블 설계
주문 관리
- 주문 취소: 주문 생성 후 5분 이내에만 취소 가능하도록 제한
- 주문 유형: 온라인 주문과 대면 주문(가게에서 직접 주문) 모두 지원
- 대면 주문 처리: 가게 사장님이 직접 대면 주문을 접수
데이터 보존 및 삭제 처리
- 데이터 보존: 모든 데이터는 완전 삭제되지 않고 숨김 처리로 관리
- 상품 숨김: 개별 상품도 숨김 처리 가능하도록 구현(숨김과 삭제는 다른 필드에서 동작해야함)
- 데이터 감사 로그: 모든 정보에 생성일, 생성 아이디, 수정일, 수정 아이디, 삭제일, 삭제 아이디를 포함
접근 권한 관리
- 고객: 자신의 주문 내역만 조회 가능
- 가게 주인: 자신의 가게 주문 내역, 가게 정보, 주문 처리 및 메뉴 수정 가능
- 관리자: 모든 가게 및 주문에 대한 전체 권한 보유
배송지 정보
- 필수 입력 사항: 주소지, 요청 사항
- ‘주문’ 과 ‘배달’ 에 모두 관련된 정보 입니다!
AI API 연동
- 상품 설명 자동 생성: AI API를 연동하여 가게 사장님이 상품 설명을 쉽게 작성할 수 있도록 지원
- AI 요청 기록: AI API 요청 질문과 대답은 모두 데이터베이스에 저장
주문 확인 방식(프론트 앤드 개발자 담당)
- 프론트엔드 폴링: 프론트엔드에서 주기적으로 주문 확인을 위해 주문 API를 호출하는 폴링 방식 사용
개발 및 인프라 확장
- 개발 속도: 빠른 개발을 통해 프로토타입을 신속히 확인
- 인프라 확장: 시스템 설계는 간결하게 유지하되, 향후 인프라 확장을 고려
기술 스택
- 프론트엔드: React.js 또는 Vue.js (권장) 및 REST API 통신
  - ⇒ 프론트 앤드 개발자가 개발 할 것!
- 백엔드: Spring Boot 3.x
- 데이터베이스: PostgreSQL
- 빌드 툴: Gradle
- 버전 관리: Git을 이용한 버전 관리 (GitHub, GitLab, Bitbucket 등)
- API 문서: 제시된 작성 툴이나 양식에 맞추어 작성
  - 프론트 엔드 개발자가 API문서만 보고도 개발 할 수 있게 작성할 것!
프로젝트 구조
- Monolithic Application
  - 해당 프로젝트는 기본적으로 모놀리틱으로 개발하며, 다음 프로젝트부터 MSA로 개발 예정
- Layered Architecture: Controller, Service, Repository 계층으로 구성된 클린 아키텍처 권장
- Entity 및 DTO: 각 기능별로 Entity와 DTO(Data Transfer Object)를 분리하여 관리
- API 설계: RESTful API 원칙에 따라 설계
- Exception Handling: 글로벌 예외 처리 (ExceptionHandler 사용)
데이터베이스 설계
- 테이블 명명 규칙: 모든 테이블에 p_ 접두사 사용
- UUID 사용: 모든 주요 엔티티의 식별자는 UUID를 사용 (유저는 예외)
- Audit 필드: 모든 테이블에 created_at, created_by, updated_at, updated_by, deleted_at, deleted_by 필드를 추가하여 데이터 감사 로그 기록
- ERD 설계: 엔티티 간의 관계를 명확히 하는 ERD(Entity-Relationship Diagram) 작성
보안
- JWT 인증: Spring Security와 JWT(Json Web Token)를 이용한 인증 및 권한 관리
- 권한 확인 : CUSTOMER 이상의 권한은 요청마다 저장되어 있는 권한 값과 동일한지 체크필요
- 비밀번호 암호화: BCrypt 해시 알고리즘을 사용한 비밀번호 암호화
- 데이터 유효성 검사: 서버 측 데이터 유효성 검사를 위해 Spring Validator 사용
테스트
- 테스트: Spring Boot Test를 사용한 테스트
- Spring Boot Test 을 반드시 사용할 필요는 없으나, 적절한 테스트 방법을 선정하여 진행
AI API 연동
- AI API 호출: AI 서비스(API)와의 연동을 위한 REST API 호출 로직 구현
- AI 응답 데이터 저장: AI API 호출 시 요청 및 응답 데이터를 DB에 저장

요구사항을 확인해보고 필수기능을 먼저 만들기위해 대략적인 API 명세서, 테이블 명세서, ERD 명세서, 인프라 설계서를 만들어봐야 할 것 같다. 요구사항이 어느정도 나와있어서 ERD 설계를 먼저 해보기로 했다.

ERD 설계서

그리고 위의 ERD 설계서를 보고 API 명세서를 작성해보았다.

API 명세는 최대한 RESTful API 원칙에 따라 작성해 프론트 엔드 개발자가 API 문서만 보고도 개발 할 수 있게 작성을 해보았다. 일부 Search 기능에는 페이지네이션기능을 추가해주었다. 각 엔티티 별로 필요한만한 API들을 만들었다.

API 명세서

그리고 다음은 ERD 명세서와 API 명세서를 바탕으로 테이블 명세서를 작성해 주었다.

테이블 명세서는 요구사항에 맞게 각 테이블명의 시작은 p_table로 시작한다. 그리고 유저 ID는 최소 4자 ~ 10자. 다른 테이블의 id는 UUID로 정의했다. 모든 테이블은 데이터 감사 로그를 기록해야하므로 created_at, created_by, updated_at, updated_by, deleted_at, deleted_by 필드를 추가했다.

테이블 명세서