Spring Boot 일정 관리 프로젝트 고민 기록

 

1️⃣DTO와 Entity의 책임 분리

객체	역할
RequestDto	클라이언트의 입력 데이터 전달 (예: 일정 생성 요청)
Entity (Schedule, Author)	도메인 객체, DB 저장/수정/삭제용
ResponseDto	클라이언트 응답용. Entity로부터 필요한 정보만 가공

✅ 저장을 위한 객체는 Entity , 응답을 위한 객체는 ResponseDto 로 명확히 구분해야 함
✅ ResponseDto  DB 저장용으로 사용하는 건 설계 상 부적절

---

2️⃣반환 타입 일치 원칙

• 메서드의 return  값은 선언된 반환 타입과 정확히 일치해야 한다.
• 예: public  ScheduleResponseDto  saveSchedule (...)  이면,
  return  뒤에는 반드시 ScheduleResponseDto  객체가 와야 함
• 실무에서는 서비스 → 레포지토리까지 모든 흐름에서 반환 타입이 일치하는지 확인하는 게 중요

---

3️⃣Entity 생성 책임 → 내부로 이동 (팩토리 메서드)

기존에는 Service에서 직접 Entity를 생성했지만,
Entity 내부에 팩토리 메서드를 두어 책임을 위임하면 더 명확한 설계가 된다.

// 이전 방식
new Schedule(dto.getTitle(), ...);

// 개선 방식
Schedule schedule = Schedule.create(dto);

 

---

4️⃣메인 유효성 검증은 Entity에서 수행

author.validateExistence();
schedule.validatePassword(input);

→ 비즈니스 도메인의 유효성 판단은 Entity의 책임
→ Service는 흐름만 조율하고, 검증은 도메인 객체에서 수행

---

5️⃣DB 시간과 Java 시간

• Java에서 new Timestamp(System.currentTimeMillis())로 만든 시간은 DB에서 가져온 값이 아님
• DB에 저장된 updated_date 를 정확히 사용하려면 insert 후 다시 select 해야 함
• 하지만 대부분의 경우, 직접 생성한 시간으로 insert & 응답을 같이 쓰면 충분히 실용적이고 효율적

---

6️⃣ScheduleResponseDto는 어떤 값을 포함해야 하는가?

• 클라이언트에게 필요한 정보만 담기 (ex. 제목, 내용, 작성자 이름, 수정일시)
• 비밀번호 같은 민감 정보는 포함 ❌
• 불변 객체로 설계하는 것이 바람직 (생성자 또는 Builder 패턴)

---

7️⃣메서드 선언 구성요소

public ScheduleResponseDto updateSchedule(Long scheduleId, String title, ...)

요소	설명
public	접근 제어자
ScheduleResponseDto	반환 타입
updateSchedule	메서드 이름
(Long scheduleId, ...)	매개변수 목록

 

---

8️⃣클라이언트 요청 흐름 정리

클라이언트 요청(JSON)
 → Controller (@RequestBody → RequestDto 매핑)
 → Service (검증 + Entity 생성)
 → Repository (DB 저장)
 → ResponseDto 생성
 → Controller 응답