🐰 [flowbit] #4. Project 도메인 도입 - 흐름의 단위를 만들었다

☘️ 1. 오늘 목표

어제는
TaskEvent를 기반으로
작업의 상태 변화를 기록하고,

그걸 조회해서
흐름을 보여주는 단계까지 왔다.

근데 여기서 딱 걸린 게 있었다.

‭→ 작업은 혼자 존재하는가?

현실에서는 그렇지 않다.

작업은 항상
어떤 단위 안에서 움직인다.

그래서 오늘 목표는 이거였다.

‭→ 작업을 하나의 흐름 단위 안에 넣자

예를 들어,

여러 작업을 동시에 진행하다 보면
각 작업의 흐름은 보이는데

→ 이 작업들이 왜 같이 존재하는지
→ 같이 어떤 방향으로 흘러가는지

는 한 번에 파악하기 어렵다.

---

☘️ 2. Task만 보면 흐름이 아니라 "점"이다

지금까지 구조는 이랬다.

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

이걸로도 흐름은 볼 수 있다.

하지만 이 작업이 왜 존재하는지는 보이지 않는다

작업 하나만 보면
흐름이 아니라 그냥 점이다.

즉,

개별 작업의 변화는 보이지만
전체 맥락은 보이지 않는다

그래서 필요한 게

‭→ Project

---

☘️ 3. Project 도메인 추가

Task 위에 Project를 하나 얹었다.

→ 여러 작업을 하나의 흐름으로 묶기 위한 단위다

구조는 이렇게 바뀐다.

Project → 흐름 단위
Task → 그 안의 작업
TaskEvent → 작업 변화

이제는

‭→ 작업 하나가 아니라
‭→ 프로젝트 안에서 움직이는 작업들이 된다

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

private String name;
private String description;

@Enumerated(EnumType.STRING)
private ProjectStatus status;

private LocalDateTime createdAt;
private LocalDateTime startedAt;
private LocalDateTime completedAt;
private LocalDateTime deletedAt;

처음이라 필드는 단순하게 잡았다.

id
name
description
status
createdAt
startedAt
completedAt
deletedAt

Project도 생성, 시작, 완료, 삭제 시점을 가질 수 있도록 했다.
나중에 프로젝트 단위 타임라인을 만들기 위해 시간 필드를 미리 열어둔 셈이다.

---

☘️ 4. Task는 무조건 Project에 속하게 했다

여기서 고민이 하나 있었다.

‭→ projectId가 null인 Task가 존재할 수 있는가?

결론은 NO

Flowbit은 애초에
흐름을 보는 시스템이라서

‭→ Task는 반드시 어떤 흐름 안에 있어야 한다

그래서 구조를 이렇게 고정했다.

‭→ Task는 반드시 Project에 속한다

---

☘️ 5. 대신 Default Project를 넣었다 ⭐

근데 매번 projectId 넣는 건 귀찮다.

그래서 타협한 게 이거다.

Default Project

동작은 간단하다.

projectId 있으면 → 그 프로젝트 사용
없으면 → Default Project 자동 연결

Optional<Project> project = projectRepository.findByName("DEFAULT");

if (project.isPresent()) {
    return project.get();
}

Project defaultProject = new Project(
        "DEFAULT",
        "기본 프로젝트",
        ProjectStatus.READY,
        LocalDateTime.now()
);

return projectRepository.save(defaultProject);

실제 구현에서는 Optional의 orElseGet을 사용해서,
DEFAULT 프로젝트가 없을 때만 새로 생성되도록 했다.

이 구조의 장점은 명확하다.

→ 구조는 깨지지 않는다
→ Task는 항상 흐름 안에 존재한다

---

☘️ 6. Task 생성 로직이 바뀌었다

기존에는 그냥

request.getProjectId()

이걸 그대로 썼는데

이제는 생성 시점에 판단한다.

null이면 → default 프로젝트 가져오기
있으면 → 존재하는지 검증

Long projectId;

if (request.getProjectId() == null) {
    Project defaultProject = projectService.getOrCreateDefaultProject();
    projectId = defaultProject.getId();
} else {
    projectId = projectRepository.findById(request.getProjectId())
            .orElseThrow(() -> new IllegalArgumentException("프로젝트를 찾을 수 없습니다."))
            .getId();
}

이걸 넣고 나니까

→ Task가 절대 고립되지 않는다

그리고 동시에

→ 사용성은 유지하면서
→ 구조를 강제할 수 있는 형태가 됐다

---

☘️ 7. Project API도 추가

Project도 외부에서 쓸 수 있어야 해서
API도 같이 만들었다.

POST /projects
GET /projects
GET /projects/{id}

프로젝트를 생성하고 단건 조회까지 확인했다.

이제 프로젝트 생성 → Task 연결 흐름이 완성됐다.

---

☘️ 8. 구조가 어떻게 바뀌었냐

이전:

• Task 중심
• 작업 단위 흐름

지금:

• Project 중심
• 프로젝트 단위 흐름

차이는 명확하다.

할 일 관리에서
흐름을 다루는 구조로 바뀌었다

---

☘️ 9. 오늘 정리

오늘 한 걸 한 줄로 정리하면 이거다.

흩어져 있던 작업들을
프로젝트라는 하나의 흐름 단위로 묶었다

---

☘️ 10. 현재 상태

Project 도메인 ✔️
Task ↔ Project 연결 ✔️
Default Project ✔️
이벤트 기반 구조 ✔️
타임라인 ✔️

이제는 진짜 흐름을 다루는 구조가 됐다

---

☘️ 11. 다음 목표

다음은 이거다.

프로젝트 단위 타임라인
프로젝트 흐름 분석

이제 한 단계 더 가면

작업 단위 흐름에서
프로젝트 단위 흐름으로 확장된다