---

📖 개요

이번 팀플 과제에서 내가 맡게된 부분은 주문/장바구니
필수단계에는 주문까지 구현이고, 장바구니는 도전 과제이지만
처음부터 우리는 장바구니를 같이 구현하는 것을 목표로 설계했다 !

---

▶️ 요구사항과 설계 내용 정리

✔️ 주문

• 고객은 메뉴 여러개를 주문할 수 있다
• 사장님은 주문을 수락할 수 있고, 배달 완료까지의 모든 상태를 순서대로 변경한다
• 주문 요청 및 상태 변경
  • 새로운 주문이거나 주문 상태가 변경될 때는 AOP로 로그를 남긴다
  • 로그 내용 - 요청 시각,가게 id,주문 id
• 제약조건
  • 가게의 최소 주문금액을 만족해야 한다
  • 가게의 오픈/마감시간이 지나면 주문할 수 없다

✔️ 장바구니

• 한 가게의 메뉴만 담을 수 있고, 가게가 변경되면 장바구니는 초기화 된다
• 장바구니는 마지막 업데이트 시점으로부터 최대 하루만 유지된다

---

📖 설계

---

1️⃣ 연관관계 설정

✔️ 연관관계 비교하기

• 🅰️ / 튜터님

  User 1 : N Cart 1 : 1 Menu
  유저는 여러 개의 Cart 항목을 가질 수 있음

  User
   ├─ Cart1 (Menu: 짬뽕, Quantity: 1)
   ├─ Cart2 (Menu: 탕수육, Quantity: 2)
   └─ Cart3 (Menu: 볶음밥, Quantity: 1)

  • 각 Cart는 메뉴 하나만 담고 있음 , 수량은 Cart에 저장
  • 복수의 메뉴를 담고 싶으면? → Cart를 여러 개 만들면 됨

• 🅱️안 / 내가 최초 생각한 연관관계

  User 1 : 1 Cart 1 : N Menu
  유저는 Cart 딱 하나만 가짐

  User
   └─ Cart1
         ├─ CartMenu (Menu: 짬뽕, Quantity: 2)
         └─ CartMenu (Menu: 탕수육, Quantity: 1)

  • Cart 안에 메뉴들이 여러 개 담겨 있음
  • "장바구니 하나 안에 메뉴가 여러 개, 거기에 수량까지 포함된 테이블"이 들어있는 구조

---

✔️ A안의 장점

1. 데이터 정규화가 깔끔함

• Cart가 메뉴 항목 + 수량으로 분리돼 있음
  → Cart만 보면 어떤 메뉴가 몇 개 담겼는지 쉽게 알 수 있음
  → 메뉴 + 수량 단위로 계산, 조회, 삭제가 아주 편해!

2. 주문 생성 로직이 깔끔해짐

• 이 구조에선 같은 주문 ID로 여러 Cart를 묶기 만 하면 끝
  → 주문 생성을 위해 메뉴 리스트 분해가 필요 없음

3. 확장성이 좋음

• 나중에 옵션, 리뷰, 쿠폰 등 기능 확장할 때도 편리할 것
  → CartItem 단위로 복잡한 로직을 분리할 수 있음

✔️ B안의 장점

1. Cart가 한 유저당 1개로 고정됨
   → 메뉴 1개만 빼려면 List<Menu>에서 꺼내서 수량 갱신하고 다시 저장해야 함

2. Cart가 메뉴 리스트를 직접 갖고 있음 → 중간 테이블 필요
   → 메뉴와 수량을 따로 저장하려면 중간 엔티티가 필요해짐

3. 비즈니스 로직이 엉켜버릴 수 있음
   → 장바구니에서 메뉴 수량 늘리기, 줄이기, 삭제하기 모두 복잡한 로직을 요구함

🌟 이해한 내용 요약 정리

A안 - cart1, cart2, cart3은 각각 짬뽕 카트, 탕수육 카트, 볶음밥 카트
B안 - cart1, cart2, cart3은 각각 수린이 카트, 광수 카트, 영식이 카트

수린이 카트에 탕수육, 짬뽕을 담을 수는 있는데
각각의 수량을 정하려면 엔티티가 하나 더 있어서 그 엔티티에 (메뉴이름,메뉴수량) 을 담아서 구현해야한다

---

✔️ A안의 Cart1,2,3은 메뉴 하나씩 담긴 독립적인 항목
✔️ B안은 Cart1이 유저 전체 장바구니 역할, 안에 메뉴와 수량 따로 들어가야 해서 중간 엔티티 필요
✔️ 그래서 실무에서는 A안을 쓰고, 필요 시 CartGroup, Order, CartItem을 붙여서 확장하는 방식 사용

---

2️⃣ 응답

• 가게의 최소주문금액을 충족했을 때만 주문이 가능하다는 조건을 보고 더 생각을 해보니
  사용자 입장에서는 장바구니에 담을때마다 현재 가격 + 주문이 가능한지 나와야 하지 않을까?

✔️ API 명세서 수정

✔️ 상황별 응답 Dto 생성

❶ 장바구니 추가시

• 방금 추가한 카트 ( 메뉴 / 수량 )
• 유저의 모든 카트의 메뉴 총합 + 유저의 모든카트 현재 금액 + 주문가능여부
  

❷ 장바구니 전체 조회 / 장바구니 수정시

• 유저의 모든카트 내용 ( 메뉴 / 수량 ) + 현재 금액 + 주문가능여부
  

🌟 Dto에서 카트 금액을 구해서 서비스단의 코드를 줄일 수 있을 것 같다...!

---

🤯 나의 회고

---

• 역시 협업에서 가장 중요한 것은 설계라는 걸 다시 한번 깨달았다..^^
  협업에서 설계단계가 70% 이상이라는 성규튜터님의 말씀이 설계단계가 다 끝나고 나니 한 번 더 생각난다..!
• dto에서 전부 가격까지 계산을 해버리게 코드를 구성했는데 이게 맞나 싶지만 stream을 활용해 가격을 다 계산해버리니까 서비스단 코드가 확줄어서 뿌듯하다~!
• 오더까지 쭉 구현해보자~!