루틴 기록 시나리오 #50
Description
⚠️ 문제 인식
사용자가 슬롯 옵션을 조정함에 따라 활성화되는 루틴 종류 및 목표량이 동적으로 변함
그에 따라 DB에 저장하고 조회해야할 루틴 종류도 날짜별로 달라짐
루틴 완료 여부를 기록하고 조회해야하기에 루틴 미체크 상황도 매일 DB에 저장해야하면서 복잡해짐
-> 루틴을 기록하는 스케줄링 시나리오를 미리 설계하고 혼란을 피하기 위해 공유
루틴 기록 스케줄링 시나리오(MVP)
하나의 루틴은 API 요청 시간대에 따라 다음 A->B->C로 처리 방법이 변함
A) 오늘의 루틴에 대한 CRUD
상황1
루틴 체크, 메모를 POST시 DB에 CHECKED, MEMO 상태로 루틴 데이터 삽입(=저장)
상황2
사용자가 이미 체크됐거나 메모된 루틴을 미체크로 변경하면 DB에서 삭제
원칙
오늘의 미체크한 루틴을 미리 DB에 삽입해놓지 않음
예시 상황
petId=1
현재 슬롯 활성화는 water(150), feed(100), skin만 된 상태
POST /api/routines/1/2025-07-01/water/check
=> ok
POST /api/routines/1/2025-07-01/feed/memo, 실제량=50, 내용=소나기
=> ok
GET /api/routines/1/daily/2025-07-01
=> 음수(체크, 150/150), 산책(메모, 50/100, '소나기')
요청 시점: 2025-07-01
상황3 (Commit 7/31 09f62)
슬롯 옵션을 활성화해놓고 CHECKED나 MEMO한 루틴이 DB에 있는 상태에서,
슬롯 옵션을 비활성화로 변경하면 해당 CHECKED나 MEMO한 루틴은 DB에서 삭제됨
B) 밤 12시가 되면 다음을 자동으로 실행
스프링 작업: 스케줄링(Batch) + 메세지 큐(Kafka) + 이메일 발송(SMTP)
- 오늘의 루틴 메모 여부 업데이트
- 오늘의 루틴 완료 여부 업데이트
- 미완료한 UNCHECKED 루틴을 DB에 삽입
루틴 업데이트된 PetId와 루틴 완료 여부 결과 내역을 petfit 운영계정 이메일로 전송함
→ petfitofficial@gmail.com
관련 이슈: #93
C) 과거의 루틴에 대한 CRUD
✅ 과거 루틴 기록을 조회할때 응답
해당 날짜로 삽입되어있는 루틴DB들을 꺼내와서 응답
과거 루틴 기록은 A와 B 과정을 거쳤다고 가정
예시 상황(위에서 이어짐)
petId=1
GET /api/routines/1/daily/2025-07-01
=> 음수(체크, 150/150), 산책(메모, 50/100, '소나기'), 피부(미체크)
요청 시점: 2025-07-02~
다음날로 지나면 B과정에 의해 피부(미체크) 루틴이 자동 저장됨
⭕ 과거 루틴 기록을 체크, 세모, 미체크로 변경 가능
과거 루틴은 DB에 기록된 루틴들만 조회하고 변경할 수 있음
예시 상황이라면 조회된 음수, 산책, 피부 루틴에 대해서만 변경 가능
예시 상황
petId=1
DELETE /api/routines/1/2025-07-01/walk/uncheck
=> ok
POST /api/routines/1/2025-07-01/skin/check
=> ok
GET /api/routines/1/daily/2025-07-01
=> 음수(체크, 150/150), 산책(미체크, 0/150), 피부(체크)
POST /api/routines/1/2025-07-01/feed/check
=> 404 ROUTINE_NOT_FOUND
요청 시점: 2025-07-02~
백엔드 주의) 같은 미체크(uncheck) 요청이라도 오늘 루틴일때와 과거 루틴일때 처리 로직이 다름
오늘 루틴 DELETE /api/routines/1/오늘날짜/walk/uncheck
=> DB에서 해당 루틴을 삭제
과거 루틴 DELETE /api/routines/1/과거날짜/walk/uncheck
=> DB에서 해당 루틴 상태를 미체크로 변경
프론트에는 두 경우 모두 루틴 응답에 산책(미체크) 포함.
❌ 과거의 슬롯 옵션은 변경 불가능
이유: 슬롯 옵션 변경할때마다 이력(로그)을 DB에 날짜나 시간별로 저장하고 반영하기에는 너무 많아지고 복잡해짐. 따라서 지난날의 슬롯 옵션은 밤12시가 되면 기록에 반영해놓고 변경 불가능한걸로
예를 들어 현재시점에 사료가 활성화된 옵션이지만 과거 조회할 날짜에는 비활성화되었던 옵션이라면 과거 루틴 기록 조회할때 사료 루틴은 응답에 포함되지 않음
예시 상황
petId=1
GET /api/routines/1/daily/2025-07-01
=> 음수(체크, 150/150), 산책(미체크, 0/150), 피부(체크)
PATCH /api/slots/1, 사료X -> 사료O
=> ok
GET /api/slots/1
=> 사료O, 음수O, 산책O, 피부X, 배변X, 치아X
GET /api/routines/1/daily/2025-07-01
=> 음수(체크, 150/150), 산책(미체크, 0/150), 피부(체크)
=> 변함없음, 사료(미체크) 항목이 추가되지 않음 않음
요청 시점: 2025-07-02~
📜 시나리오와 관련된 API
Routine
GET /api/routines/{petId}/daily/{date}
Entry
GET /api/entries/{petId}/monthly/{month}
GET /api/entries/{petId}/weekly/{week}
GET /api/entries/{petId}/daily/{date}
위 API들은 수정 혹은 추가 예정
그 외에 슬롯(Slot), 특이사항(Remark), 일정(Schedule) API는 변화 없음
🔨 스웨거/포스트맨 QA시 예상되는 에러사항과 보완책
B과정은 매일밤 12시에 활성화된 슬롯 옵션을 확인해서 미완료된 루틴을 DB에 추가하는 방식
따라서 QA때 스웨거나 포스트맨에서 목데이터로 다른 날짜의 루틴들을 운영환경처럼 저장하고 확인하기 힘듦
(오늘이 지날 때까지 기다려야 오늘 루틴 데이터들만 DB에 완전히 저장됨)
하루 기록 수동 업데이트 API
위를 보완하고자 테스트용으로 해당 날짜의 B과정을 수동으로 시행하는 다음 API를 제작
POST /dev/flush
=> B과정을 수동으로 시행
=> 현재 활성화된 슬롯 옵션 중에 미체크인 루틴들을 DB에 저장
=> 그날의 루틴 완료 여부 업데이트
차이는 운영환경에서는 과거 해당날짜의 활성화된 슬롯 옵션 중에 미체크인 루틴들을 DB에 저장한다는것
테스트 시나리오 참고
용어 정리
| 용어 | 의미 | 사용처 |
|---|---|---|
| 루틴 상태 | 체크(CHECKED), 메모(MEMO), 미체크(UNCHECKED) | Routine API, Entry API |
| (일간) 루틴 완료 | 하루의 모든 루틴이 체크나 메모된 상태 | Entry API |
| (일간) 루틴 미완료 | 하루에 1개 이상의 미체크 루틴이 존재하는 경우 | - |
진행 현황
| 대상 | 진행 |
|---|---|
| A) 오늘의 루틴에 대한 CRUD | 구현 완료 |
| B) 밤 12시가 되면 Batch 자동으로 실행 | 시작전 |
| C) 과거의 루틴에 대한 CRUD | 구현 완료 |
| 하루 기록 수동 업데이트 API | 구현 완료 |
| #50 |