BaseEntity / AuditBaseEntity 구조 도입 제안

[chanbyoung]

공통 엔티티 필드 관리를 위해 다음과 같은 추상 클래스 구조를 도입하고자 합니다

• AuditBaseEntity: 생성일 / 수정일 필드 자동 관리 (@CreatedDate, @LastModifiedDate)
• BaseEntity: 논리 삭제용 isDelete 필드 및 markAsDeleted() 메서드 제공

기대 효과

• 엔티티 간 공통 필드 중복 제거
• JPA Auditing 기반 자동 시간 관리
• 논리 삭제 플래그 일관 적용

✅ 사용 예시

📌 AuditBaseEntity 사용 예시

@MappedSuperclass
public class AuditBaseEntity {

    @CreatedDate
    @Column(name = "created_time")
    private LocalDateTime createdTime;

    @LastModifiedDate
    @Column(name = "updated_time")
    private LocalDateTime updatedTime;
}

📌 BaseEntity 사용 예시

@MappedSuperclass
public abstract class BaseEntity extends AuditBaseEntity {

    private boolean isDelete;

    public void markAsDeleted() {
        this.isDelete = true;
    }
}

[thelightway24]

좋은 제안이라고 생각합니다.
다만, 해당 기능에 익숙하지 않은 분들도 계실 수 있으니,
어떤 상황에서 해당 구조가 필요한지 구체적인 예시를 함께 들어주시면 이해에 더 도움이 될 것 같습니다.

그리고 클래스 이름도 조금 더 의도가 명확하게 드러나도록 변경하면 어떨까 합니다.
예를 들어,
• BaseEntity → SoftDeletedEntity (삭제 가능한 엔티티라는 점을 명시)
처럼 네이밍을 구체화하면 더욱 직관적일 것 같습니다.

어떻게 생각하시나요?

[chanbyoung]

BaseEntity가 AuditBaseEntity를 상속받고 있는점을 고려해야될거 같은데 다른 네이밍을 한번 고민해 볼게요!

[thelightway24]

네. BaseEntity를 사용하면 안되는 건 아니지만 작성하신 예제처럼 한정해서 사용한다면 너무 포괄적인 이름이 아닐까요?

[thelightway24]

클래스 이름만으로도 역할과 특성을 쉽게 파악할 수 있다는 점을 말씀드린 것이라 반드시 수정하실 필요는 없습니다.

이미 익숙하신 내용이겠지만, 의도를 좀더 분명히 전달드리기 위해 예시를 들어보면:
자바의 ArrayList 상속 구조는 다음과 같으며, 클래스 이름만 보고도 대부분의 동작 방식을 짐작할 수 있습니다.

ArrayList: 배열(Array)로 구현된 리스트
← List: 리스트 자료형
← SequencedCollection: 순서 보장
← Collection: 자바 컬렉션 공통 기능(추가·삭제·조회 등)
← Iterable: 반복 가능(for-each, 스트림 등)
각 상위 인터페이스가 담당하는 기능을 계층적으로 정의하도록 설계된 구조입니다.

[chanbyoung]

고려해서 추가해볼게요!!!

[thelightway24]

고려해서 추가해볼게요!!!

다른 분들 의견도 더 들어보면 좋을 것 같은데 아쉽네요ㅠㅠ

[LEELISE]

도입해야하는 이유가 적절하니 도입해보아도 좋을 것 같습니다.
다만, 위에서 예정님께서 언급해주신대로 처음 접해보는 구조이다보니 사용하실 때 주석을 상세하게 달아주시면 도움이 될 것 같습니다.