[TIL] 배달 앱 아웃소싱 프로젝트

• 프로젝트 명 : 오늘은 뭐먹지?(What The Eat)
• 소개
  • 한 줄 정리 : 오늘은 뭐먹지? 매일 선택의 순간에 놓인 당신을 위한 한 끼 추천 서비스
• 진행 날짜 : 2024.12.03 ~ 2024.12.09

 

프로젝트 요약

1. 프로젝트 목적

• Spring Boot + JPA를 활용한 도메인 설계 및 연관관계 매핑
• Soft Delete 기법을 통한 데이터 관리 방식 이해
• 예외 처리 및 공통 응답 적용을 통한 안정적인 API 설계
• Enum을 활용한 상태 관리와 비즈니스 로직 캡슐화
• 팀 내 코드 리뷰 및 리팩토링을 통한 유지보수 향상

2. 프로젝트 구현

<필수 구현>

• 회원 관리 : 회원가입, 로그인, 회원 탈퇴
• 가게 관리 : 사장님이 가게 등록, 수정, 조회, 폐업 가능
• 메뉴 관리 : 사장님이 메뉴 추가, 수정, 삭제
• 주문 관리 : 고객이 주문 생성, 사장님이 주문 상태 관리
• 리뷰 관리 : 고객이 리뷰 작성, 가게별 리뷰 조회

<도전 구현> - 구현 X

• 장바구니
• 관리자
• 포인트 및 쿠폰
• 소셜 로그인
• 이미지 저장
• 주문 강화
• 메뉴 강화
• 가게 강화

---

사용한 기술 및 개념
& 맡은 역할

1. Backend

기술 스택	목표
Spring Boot	RESTful API 설계 및 엔티티 관리
Spring Data JPA	ORM을 활용한 데이터 저장 및 조회 최적화
Spring MVC	컨트롤러 계층 설계 및 서비스 로직 분리
Lombok	코드 간소화 및 가독성 개선(@Getter, @Builder 등)
BCrypt	보안 강화를 위한 비밀번호 암호화 및 검증

2. Database

• MySQL
  • 관계형 데이터베이스 관리 시스템(RDBMS)
  • SQL(Structured Query Language)을 사용해 데이터베이스 CRUD 가능
• ERD
  • 데이터베이스 설계 시 Entity 간의 관계를 시각적으로 표현

3. Tool

• Postman
  • API 요청 & 응답 테스트 도구
  • 프로젝트에서 구현한 RESTful API를 테스트하고 상태 코드(200, 404 등)와 응답 데이터 확인
• IntelliJ IDEA
• Git / Github

4. 팀 내에서 맡은 역할

• 주문 관리
  • 주문 생성 API(최소 주문 금액, 영업 시간, 가게 상태 검증)
  • 주문 상태 변경 API(사장님 주문 진행 상태 관리)
  • 주문 내역 조회 API(고객, 사장 각각 조회 방식 구현)
• 리뷰 관리
  • 리뷰 생성(배달 완료된 주문에 대해서만 리뷰 작성 가능하도록 제한)
• 전체 코드 리팩토링

---

팀에서 구현한 내용
& 내가 구현한 내용

1. 프로젝트 설계

-와이어프레임

 

-API 명세서 작성

 

-ERD 작성

 

2. 구현기능 - 내가 맡은 부분

• 주문(Order) 관리 구현
  • 구현 내용
    • 고객이 주문을 생성할 수 있으며, 최소 주문 금액 및 가게 영업 상태를 검증
    • 사장님이 주문 상태를 변경할 수 있음(enum에서 변경 순서를 강제로 적용)
    • 고객은 자신의 주문 내역을 확인할 수 있고, 사장님은 특정 가게의 주문 내역을 조회 가능
  • 적용 기술 및 개념
    • JPA를 활용한 엔티티 설계 및 연관관계 매핑
      • User, Order, Menu, Shop 엔티티 간 연관관계 설정
      • @ManyToOne을 사용하여 주문-메뉴-가게-사용자 간 관계 매핑
    • 비즈니스 로직 캡슐화
      • Order 엔티티 내부에서 총 주문 금액을 자동 계산
      • 최소 주문 금액 및 영업 시간 검증을 주문 생성 시점에서 수행
    • Enum을 활용한 주문 상태 관리
      • ORDERED -> ACCEPTED -> PREPARING -> COOKED -> DELIVERING -> DELIVERED 순서로만 변경 가능하도록 제한
      • canTransitionTo를 사용하여 Enum 내부에서 순서 강제 적용

public enum OrderStatus {
    ORDERED, 
    ACCEPTED,
    PREPARING, 
    COOKED,
    DELIVERING, 
    DELIVERED;

    public boolean canTransitionTo(OrderStatus nextStatus){
        return switch (this){
            case ORDERED -> nextStatus == ACCEPTED;
            case ACCEPTED -> nextStatus == PREPARING;
            case PREPARING -> nextStatus == COOKED;
            case COOKED -> nextStatus == DELIVERING;
            case DELIVERING -> nextStatus == DELIVERED;
            case DELIVERED -> false;
        };
    }
}

• 리뷰(Review) 생성 기능 구현
  • 구현 내용
    • 배달 완료된 주문에 대해서만 고객이 리뷰를 작성할 수 있도록 제한
    • 동일 주문에 대해 한 번만 리뷰 작성 가능하도록 함
  • 적용 기술 및 개념
    • JPA 연관관계 설정
      • Review와 Order를 1:1 관계로 설정
      • 한 개의 주문에 하나의 리뷰만 작성할 수 있도록 @OneToOne, unique=true 적용
    • 비즈니스 로직 구현
      • 리뷰 작성 시 주문 상태가 DELIVERED인지 확인
      • 이미 작성된 리뷰가 있는지 검증하여 중복 리뷰 방지

3. 리팩토링

• 리팩토링 목표
  • 컨트롤러 계층에서 반환 타입 일치시킴
    • 문제 
      • 일부 컨트롤러에서 ResponseEntity<T>를 반환하고, 일부는 T만 반환하는 방식을 사용
      • API 응답의 일관성이 부족하여 클라이언트에서 처리하기 어렵고, 유지보수성이 떨어짐
    • 해결 방법
      • 모든 컨트롤러의 반환 타입을 ResponseEntity<T>로 통일하여 명확한 HTTP 응답 코드와 데이터를 포함하도록 변경
  • DTO 클래스에 final 키워드 적용하여 불변성 보장
    • 문제
      • DTO 클래스에서 final 키워드가 빠져 있어, 객체가 변할 가능성이 있었음
      • DTO는 데이터 전달용으로 사용되므로 불변성을 유지하는 것이 좋음
    • 해결 방법
      • 모든 DTO 클래스 필드에 final 키워드를 추가하여 불변성 보장
  • 빠진 예외처리 추가
    • 문제
      • 일부 로직에서 예외 처리가 빠져 있어 예상치 못한 오류가 발생할 가능성이 높았음
    • 해결 방법
      • 예외 발생 시 명확한 메시지를 반환하도록 추가 처리
  • 전체 코드 컨벤션 맞춰서 가독성 및 유지보수 개선
    • 문제
      • 컨트롤러, 서비스, DTO 등 일부 코드에서 변수명, 줄바꿈, 코드 스타일 등이 통일되지 않음
      • 일부 메서드에서 불필요한 코드가 포함되어 있어 가독성이 떨어짐
    • 해결 방법
      • 코드 컨벤션을 맞춰 가독성을 향상
      • 불필요한 코드 정리 및 일관된 네이밍 적용
      • Lombok의 @RequiredArgsConstructor를 활용하여 의존성 주입 방식 통일

---

진행 중 어려웠던 점과 해결방법
& 피드백

1. 진행 중 문제점과 해결방법은 트러블 슈팅을 작성해 정리

https://jy3574.tistory.com/118

[트러블 슈팅] 아웃소싱 프로젝트

2. 설계에 관한 피드백

-API 설계 피드백

• 전반적으로 Restful한 API 설계가 잘 이루어짐
• menuStatus 관리 방식
  • 현재 TINYINT(1,0)로 관리되지만, 보다 명확한 상태를 나타내기 위해 Enum 사용 권장
  • Boolean 값(true/false)과 Enum의 장단점을 이해하고 적용
    • 메뉴 주문 시 최소 주문 금액 검증 로직 개선 필요
• API 상에는 PREPARING 상태로 변경 요청이 들어오게 표시되어있는데, 다른 상태 변경 방식은 어떻게 적용할 것인지 명확하게 작성

-ERD 설계 피드백

• 식별자 ID의 타입을 BIGINT로 설정하여 확장성 고려
• Enum 값은 DB에 String으로 저장됨을 인지하고 설계 반영
• Soft Delete 및 데이터 추적을 위해 BaseEntity 활용 

-역할 분담 및 스코프 관리

• 역할 분담이 적절하게 이루어짐
• 작업 속도 차이를 고려한 팀원 간 협업
  • 인증/인가가 가장 먼저 끝나야 함

3. 코드 구현 후 최종 피드백

• 인증 및 인가 관련 - 인터셉터를 활용한 인증/인가 처리
  • 인터셉터를 사용하여 인증/인가를 깔끔하게 처리
  • 세션 기반 사용자 인증을 통해 API 접근 권한을 제한
• 코드 네이밍 및 디렉토리 구조
  • Const 클래스의 네이밍 개선 필요
    • Const.LOGIN_USER -> Authentication.User_ID 형태로 의미를 명확히 하는 것이 좋음
  • 디렉토리 구조 개선 가능성
    • Entity 별로 디렉토리를 구분하는 방식과 비교하여 장단점 분석 필요
• 예외 처리 및 유효성 검사
  • Order 엔티티 필수값 검증 방식
    • 현재 컨트롤러 내부에서 수동 예외 처리 -> @Valid 및 @NotNull을 활용한 Bean Validation 적용 필요
  • Shop 관련 Request에 Validation 누락됨 -> 유효성 검사 추가 필요
  • @ExceptionHandler의 응답 형태 통일 필요
• 리팩토링 필요 사항
  • Javadoc 사용 권장
  • 불필요한 주석 제거 및 코드 컨벤션 정리
• 데이터베이스 관련 최적화
  • RAND() 함수 사용에 대한 고민 필요
    • MySQL의 RAND() 함수를 사용하면 DBMS 변경 시 SQL 수정 필요
    • 데이터베이스 종속성을 줄이는 방식 고민 필요 (e.g., 애플리케이션 레이어에서 처리)
  • DDL 설정 방식 변경

---

느낀점 및 개선해야할 점