투두의 startAt과 endAt을 어떻게 처리해야 할지가 너무 어렵다.. 반복되지 않는 하루짜리 단일 투두의 로직은 매우 간결하지만, 기간이 하루가 아닌.. 예를 들면, '8월 3일 ~ 8월 5일까지 오후 4시에 수행해야 하는 투두'와 같은 것을 어떻게 처리해야 할지가 고민이었다.
처음 생각해본 방식은 다음 2가지였다.
반복 투두 생성 방식
하나의 투두의 startAt을 8월3일16시, endAt을 8월5일16시로 설정하여, 하나의 투두로 관리한다.
- 장점
- 설계가 매우 쉽고, 명확하다.
- 단점
- 이러면 '반복'이라는 느낌이 들지 않는다.
- 따지고 보면 3일동안 수행을 하는 것인데, 하나의 투두는 3일을 하나의 객체로 관리하기에 이 3일 동안의 처리 과정을 트레이싱하기 어렵다.
- 마찬가지로 하나의 객체로 관리되기에 하루하루의 관점으로 보지 않아 수정 및 삭제가 용이하지 않다.
- 가장 큰 문제는 우리 서비스는 그날 그날 투두 수행에 관한 보상을 지급해야 하는데, 하루 단위의 인스턴스를 관리하는 관점이 아니므로 보상 지급에 대해서도 어려움이 있다.
- 쉽게 말해, 설계는 너무 쉽지만 비즈니스 로직 구현이 너무 복잡해질 것 같다.
바로 폐기. 역시 문제는 우리 서비스 특성상 하루하루의 투두 수행 여부를 관리해야 하므로, 투두가 1일보다 큰 범위를 갖는 것은 다른 방식의 처리가 필요해보였다. 그래서 생각한 방식은 이렇다.
startAt과 endAt 사이의 간격이 하루를 넘어가는 투두의 경우, '반복'하는 투두로 간주하고 '반복정보'와 '인스턴스'를 생성한다.
- 장점
- 이제 수행 기간이 하루를 넘어가는 투두 역시 하루 단위로 투두를 관리할 수 있게되었다.
- 각 인스턴스를 기준으로 다양한 처리가 가능해지며, 그에 따른 차등 보상 역시 가능하다.
- 확장성이 좋다.
- 단점
- 구현이 조금 어렵다.. 특히, 수정 및 삭제의 경우가 조금 귀찮다.
Todo
와TodoInstance
를 구분하여 따로따로 처리를 해주어야 한다. (Todo
와TodoInstance
는 1:N 관계)Todo
의 의미가 조금 모호해진다.- 예를 들면,
[8월 5일 5시~6시]에 시작해서 [8월 7일 5시~6시]까지 수행하는 투두
를 생성한다고 해보자 - 이를 표현하기 위해서는
startAt=8월 5일 5시, endAt=8월 5일 6시, 반복 정보='매일 반복, 3번'
이라는 정보를 입력받게 된다.- 그 결과로
8월 5일 ~ 8월 7일까지 수행하는 투두
라는 의미를 담는 하나의 Todo 엔터티가 생기고, 이와 관계를 맺는,8월 5일의 인스턴스
,8월 6일의 인스턴스
,8월 7일의 인스턴스
가 생성된다.
- 그 결과로
- 하지만, 이렇게 되면 TodoInstance의 부모인 Todo가 의미가 모호하다..
- 예를 들면,
과거의 나는 일단은 후자의 방식을 그대로 취하여 Todo
와 TodoInstance
를 구분하고, 1:N 관계를 맺는 방식을 취했다.
하지만.. 해보니 너무 구현이 번거롭고 이게 맞는지 의문이 들었다..
관련된 로직을 아주 대충 소개하면,
- 투두 생성 로직
- 유저 정보와 투두 생성 요청 데이터를 바탕으로
Todo
를 만든다 - '반복 정보'가 요청 데이터에 없을 경우, 단일
Todo
로 간주하고, 단순 생성 후 로직을 종료한다. - 있을 경우,
TodoInstance
로 간주하고RepeatInfo
생성 및,TodoInstance
를 생성한다.- 반복 정보를 참고하여, 반복 빈도가 'DAILY'인지, 'WEEKLY'인지, 'MONTHLY'인지에 따라 다른 생성 로직을 수행한다.
- 만약 생성된
TodoInstance
가 1개 일경우, 단일Todo
와 다름없으므로TodoInstance
를 생성하지 않는다.
- 유저 정보와 투두 생성 요청 데이터를 바탕으로
- 투두 정보 및 상태 업데이트, 삭제 로직
- 업데이트하려는 대상이,
Todo
인지TodoInstance
인지 여부와TodoInstance
라면 하나의 인스턴스만 수정할지, 관련된 모든 인스턴스를 수정할지를 쿼리 파라미터로 받아야 한다. Todo
라면 단순히 해당Todo
만 수정 및 삭제한다.TodoInstance
이고 하나의 인스턴스 대상일경우, 역시 해당 인스턴스만 수정 및 삭제한다.TodoInstance
이고 모든 인스턴스 대상일경우, 모든 인스턴스를 수정하고, 그 부모Todo
역시 이를 반영하도록 2중 수정을 해주어야 한다. (이게 너무 마음에 걸렸다..)
- 업데이트하려는 대상이,
문제점
Todo
는 단순히TodoInstance
의 부모 역할만 할 뿐, 아무 의미도 없어지고 관리 포인트만 늘어나는 느낌이다.TodoInstance
생성 시의RepeatInfo
는 단순히 반복 정보만을 저장하고 있고, 외에는 아무 역할을 하지 않는다.
=> 반복 일정의 경우 Todo
가 의미가 없어지고, RepeatInfo
는 단순히 정보만 담고 아무 역할을 하지 않는다..
=> 의미는 없는데 연관관계로 인해 불필요한 수정이 계속해서 발생한다.
개선된 투두 관리
TodoInstance라는 개념을 삭제하고 대신, RepeatInfo를 통해 반복되는 Todo를 관리하자
=> Todo
:RepeatInfo
= 1..N:0..1
=> Todo에게 RepeatInfo가 있을 경우, 반복되는 Todo로 간주하면 된다! (기존의 불필요했던 Todo:TodoInstance 관계를 Todo:RepeatInfo로 대체)
- 투두 생성 로직
- '반복 정보'가 요청 데이터가 없을 경우, 하나의
Todo
를 생성한다 - '반복 정보'가 요청 데이터가 있을 경우,
RepeatInfo
를 생성하고, 그 자식으로Todo
를 여러개 생성한다(RepeatInfo:Todo
=0..1:1..N
)
- '반복 정보'가 요청 데이터가 없을 경우, 하나의
- 투두 정보 및 상태 업데이트, 삭제 로직
- 업데이트하려는
Todo
가RepeatInfo
를 갖고 있지 않을 경우, 단일 투두이므로, 단순히 해당Todo
만 수정 및 삭제한다 - 업데이트하려는
Todo
가RepeatInfo
를 갖고 있을 경우, 반복되는 투두로 간주하고, 수정 범위(반복 투두 하나, 반복 투두 전체)를 체크한다.
- 업데이트하려는
=> 더 이상 Todo와 TodoInstance를 분리하지 않게되었으며, 불필요한 수정을 제거할 수 있게 되었다!
'Project' 카테고리의 다른 글
[TODOMON] EP.3 펫 정보 저장 방식에 대한 고민 (0) | 2025.01.28 |
---|---|
[TODOMON] EP.2 투두 달성 보상 기능 (1) | 2025.01.28 |
[MY-WAS] 나만의 WAS 만들기 프로젝트 (완) - HTTP 헤더 캐시 (0) | 2025.01.12 |
[MY-WAS] 나만의 WAS 만들기 프로젝트 (3) - Session & Cookie & JSON (0) | 2025.01.11 |
[MY-WAS] 나만의 WAS 만들기 프로젝트 (2) - 커맨드 패턴, 리플렉션, 애노테이션 (0) | 2025.01.11 |