[BE] Auditing 기능 및 삭제 정책 결정

[BomLee427]

✅ 구현할 기능

• JPA Auditing 활성화하여 리소스 생성/수정 시각 자동 업데이트
• 삭제 시 soft delete 여부, soft delete한다면 삭제된 데이터 이전 여부/보관 기한 등 리소스 삭제 정책 결정 필요

🔨 상세 작업 내용

• [x] 삭제 정책 논의
• [x] JPA Auditing Enable
• [x] 공통 필드(createdAt, updatedAt, deletedAt 등) 상속받을 Parent class 작성

📄 참고 사항

⏰ 예상 소요 기간

3시간

[github-actions[bot]]

Branch feature/issue-19 created for issue: [BE] Auditing 기능 및 삭제 정책 결정

[chea-young]

공통 필드(createdAt, updatedAt, deletedAt 등) 상속받을 Parent class 작성 항목에 대해서 기존에 관리할 때, createdAt, updatedAt, deletedAt를abstract class 로 보통 관리하며 이커머스 혹은 서비스의 성격에 따라 @CreatedBy, @LastModifiedBy 추가하여 데이터가 생성되거나 수정될 때 유저의 ID를 관리할 수 있도록 abstract class에 추가하여 사용하기도 하였었습니다.

하지만, 일정관리 시스템이기 때문에 createdAt, updatedAt, deletedAt 정도면 충분할 것 같다고 생각합니다!

[jifrozen0110]

저는 soft delete랑 hard delete랑 혼용해서 사용하곤 했습니다. 유용한 데이터 user는 소프트 delete 굳이 유저가 삭제하는 데이터 일정?과 같은 부분은 용량을 위해 hard delete를 했던것같습니다! 아니면 노션처럼 휴지통으로 보낸뒤 3일뒤 hard delete와 같은 정책을 가져갈 수도 있겠어요!

공통 필드의 경우 저는 createdAt createdBy modifiedBy modifiedAt을 사용했습니다. 개인 일정관리라면 수정자가 필요없을것같은데 나중에 커뮤니티 그룹과 같은 확장성을 고려하면 또 필요할 것 같기도 합니다..!!