🐰 [flowbit] #2. TaskEvent 도입 - 상태를 저장하지 말고, 변화를 기록하자

☘️ 1. 오늘 목표

어제는 Task CRUD까지 만들었다면,
오늘은 flowbit의 핵심 구조를 만드는 날이었다.

→ 상태를 저장하는 게 아니라, 상태 변화를 기록하는 구조

---

☘️ 2. 왜 TaskEvent를 만들었나

기존 구조는 단순했다.

Task.status = TODO / IN_PROGRESS / DONE

작업이 특정 상태(BLOCKED 등)가 되었을 때

왜 막혔는지
언제부터 막혔는지
그 전에 어떤 상태였는지

를 알 수 없었다

그래서 구조를 이렇게 나눴다.

Task → 현재 상태
TaskEvent → 상태 변화 이력

즉,

상태 = 결과
이벤트 = 과정

결과만 보면 알 수 없는 정보를
과정으로 다시 추적할 수 있게 된다

---

☘️ 3. TaskEvent 설계

TaskEvent는 상태 변화 자체를 기록하는 객체다.

public class TaskEvent {
    private Long taskId;
    private TaskEventType eventType;
    private TaskStatus fromStatus;
    private TaskStatus toStatus;
    private String description;
    private LocalDateTime createdAt;
}

핵심 필드만 보면:

eventType → 어떤 이벤트인지
fromStatus → 이전 상태
toStatus → 변경된 상태
createdAt → 발생 시점

이 구조로 상태 흐름을 그대로 복원할 수 있다.

TODO → IN_PROGRESS → DONE

---

☘️ 4. 상태 변경 API 구현

단순 CRUD를 넘어서 상태 변경 API를 만들었다.

PATCH /tasks/{id}/start

→ TODO → IN_PROGRESS

PATCH /tasks/{id}/complete

→ IN_PROGRESS → DONE

PATCH /tasks/{id}/block

→ TODO / IN_PROGRESS → BLOCKED

PATCH /tasks/{id}/delete

→ 어떤 상태든 → DELETED

아래는 실제로 Task를 생성한 뒤 삭제했을 때의 이벤트 로그이다.

상태만 바뀌는 게 아니라 CREATED → DELETED 흐름이 그대로 기록되는 것을 확인할 수 있다.

---

☘️ 5. 이벤트 기록 흐름

상태 변경 시 처리 흐름은 다음과 같다.

현재 상태 조회
상태 변경
TaskEvent 생성
DB 저장

예시:

STARTED:
TODO → IN_PROGRESS

COMPLETED:
IN_PROGRESS → DONE

위 TaskEvent 테이블 데이터를 보면 단순히 상태 값만 바뀌는 게 아니라

CREATED → STARTED → COMPLETED

처럼 상태 변화 과정 자체가 그대로 남는다

작업에 따라

→ BLOCKED
→ DELETED

같은 흐름도 함께 남는다.

---

☘️ 6. 이벤트 조회 API

GET /tasks/{id}/events

응답 예시:

[
  { "eventType": "CREATED" },
  { "eventType": "STARTED" },
  { "eventType": "COMPLETED" }
]

이걸로 작업의 전체 흐름을 확인할 수 있다.

단순히 현재 상태가 아니라
어떻게 이 상태에 도달했는지까지 볼 수 있다

---

☘️ 7. 이 구조의 trade-off

이벤트 기반 구조는 모든 상태 변화를 기록하기 때문에
데이터가 계속 누적되고, 조회 시 복잡도가 증가한다.

특히 특정 시점의 상태를 재구성하거나 전체 흐름을 조회할 때 성능에 대한 고려가 필요하다.

이 문제는 캐싱이나 조회 구조 최적화를 통해 해결할 수 있다고 판단했다.

---

☘️ 8. 구현하면서 느낀 점

처음에는 단순히 status 값만 바꾸는 구조였다.

task.setStatus(DONE);

지금은 이렇게 바뀌었다.

task.complete();
taskEventRepository.save(...);

단순히 status 값을 변경하는 구조에서

상태 변화를 행위로 표현하는 구조로 바뀌었다

이로 인해

상태 변경이 단순 값 변경이 아니라
의미 있는 이벤트로 기록된다

결과적으로

데이터 관리 방식이 상태 중심에서
흐름 중심으로 전환되었다

---

☘️ 9. 오늘 배운 핵심

상태는 결과일 뿐이다
중요한 건 변화 과정이다
도메인 객체가 상태 변경을 책임져야 한다
Service는 흐름을 조합하는 역할이다

결국,

상태를 저장하는 시스템이 아니라
흐름을 기록하는 시스템으로 전환됐다

---

☘️ 10. 현재 상태

CREATE ✔️
READ ✔️
START ✔️
COMPLETE ✔️
BLOCK ✔️
DELETE ✔️
EVENT LOGGING ✔️

단순 CRUD에서 벗어나
상태 변화까지 기록하는 구조까지 확장했다.

---

☘️ 11. 다음 목표

상태 기반 조회 (GET /tasks?status=TODO)
Project 도메인 추가
이벤트 조회 고도화