[DISCUSSION] driven-command에서 사용되는 JPA Config 관련 질문입니다.

[taewookimm]

이슈 개요

@CreatedDate, @LastModifiedDate 사용을 위해 @EnableJpaAuditing 어노테이션을 JpaConfig 클래스를 만들어야 하나, @EnableJpaAuditing 어노테이션을 사용하지 않고 createdAt, updatedAt의 값을 수동으로 넣어주는 방식으로 가야 하나 고민이 생겼습니다.

부연 설명

해당 이슈에 대해 @github-insu 님과 먼저 의견을 나누었고, 같이 리서치를 했습니다.
JpaConfig를 작성하면 JPA 의존도가 높아져 나중에 DB 또는 ORM을 변경할 때 불필요한 작업이 생길까?라는 의문점도 생겼고, 그렇다기엔 JpaConfig로 관리를 하는 게 불필요한 중복 코드도 방지할 수 있고, 유지 보수에 좋다고 생각했습니다.

현재 저희가 진행하고 있는 헥사고날 아키텍처에 어떤 방식이 더 잘 어울릴지 고민이 되었습니다.
그래서 어떤 방식이 더 좋을지에 대해 팀원들의 생각이 궁금합니다!

JpaConfig, 직접구현 리서치 결과

JpaConfig

• 장점
  • 표준화된 접근
  • 적용 범위 관리
  • 유지보수 용이
• 단점
  • JPA 의존성
  • 커스터마이징 한계
  • 헥사고날 아키텍처와 충돌 가능성

직접 구현

• 장점
  • JPA 의존성 제거
  • 높은 커스터마이징
  • 헥사고날 아키텍처 준수
• 단점
  • 코드 중복 가능성
  • 직접 관리의 부담
  • 추가 구현 작업(다중쓰레드 환경에서 동기화 이슈 고려해야 할 수도 있습니다.)

---

@EnableJpaAuditing 설정 참고 ( @github-insu 님 리서치 결과 )

• 헥사고날 아키텍처 관점에서 봐도 @EnableJpaAuditing이 Application 메인 클래스에 있으면 핵심 도메인 로직에 인프라스터럭처 코드(JPA코드)가 있는 것이라서 문제가 생길 수도 있다고 합니다.

[merge-simpson]

@taewookimm 님, @github-insu 님!
JPA를 사용하는 어댑터 영역의 테스트 코드와 주요 일정으로 바쁘신 와중에도
좋은 고민이 담긴 논의 제안 감사드립니다. 👍

이하 내용은 제 생각을 정리한 것입니다.
다른 분들께서도 이 코멘트로 인해 생각을 제한하시기보다 다양한 아이디어를 모아 보는 배경 공유로 봐 주시면 좋겠습니다!

---

질문 내용의 정리

다음 중 한 방식을 선택하기 위해 고민하는 것으로 이해하고 있습니다.

• JpaConfig 클래스 생성 및 @EnableJpaAuditing 사용 (JPA 의존적인 관리)
• Instant.now()로 createdAt 및 updatedAt 필드의 값을 직접 주입 (JPA 독립적인 관리)

이 코멘트의 요약

저는 Instant.now()로 직접 입력하는 것을 선호하며, 이로써 데이터베이스에 더 많은 제어 능력을 가진 설계를 유지해 줍니다. 그러나 필요할 때만 createdAt, updatedAt 컬럼을 직접 제어하는 관점에서 보면, 그러한 제어 능력으로 인해 취득하는 편의가 적으며, 이로 인하여 생기는 실수를 감수하기보다 설계적 안정성을 우선시하는 관점이 있을 수 있습니다.

JpaConfig 클래스를 만드는 것은 위 선택지에 의해서도 필요할 수 있지만, 다른 이유로도 필요할 수 있으므로 생성 위치를 미리 고려합니다.

• Common 패키지를 사용한다면 me.nettee.common.jpa.config 패키지에 JpaConfig를 만들 수 있습니다.
• Core 패키지를 사용한다면 다음처럼 선택할 수 있다고 생각합니다.
  • 단일 모듈 프로젝트: me.nettee.core.jpa.config 패키지에 JpaConfig를 만들 수 있습니다.
  • 멀티 모듈 프로젝트: nettee.jpa.config 패키지에 JpaConfig를 만들 수 있습니다.

---

💊 @EnableJpaAuditing 애노테이션의 적용

✅ 제안된 두 방식은 모두 간편한 방식입니다.

그중 JPA 사용의 의의를 높이기 위해 createdAt, updatedAt 필드를 자동으로 관리함으로써, 시간 타입 관리에 대한 실수를 줄일 수 있다는 점이 @CreatedDate, @LastModifiedDate 애노테이션을 권장하는 이유 같습니다.

저는 개인적으로 Instant.now()를 사용해서 직접 입력하는 것을 선호합니다. 서버 애플리케이션에서 DB 테이블에 더 많은 제어 능력을 갖춘 설계를 유지하고 싶기 때문입니다. 단, 보수적인 설계 관점에서 이러한 조치는 '필요할 때만' 하는 것이 더 바람직할 수 있습니다.

협업에서 한 가지를 선택한다면 팀 내 협의에 따라 결정하겠지만, 일반적인 기호에 따라 @CreatedDate, @LastModifiedDate 애노테이션을 권장하려고 합니다.

✅ 두 제안 사이의 고민이 아니더라도 JpaConfig는 언젠가 필요한 설정입니다.

일부 영역에서 createdAt, updatedAt을 직접 관리하더라도, 전체 협업 중 언젠가 JPA Config 관리가 필요할 수 있습니다. 따라서 JPA Config를 만드는지 여부는 해당 선택지와 일면 종속적이면서도, 독립적인 논제가 될 수 있다고 생각합니다.

@EnableJpaAuditing 애노테이션의 적용 위치 (스프링 부트 애플리케이션 vs Configuration)

메인 애플리케이션 클래스보다 설정 파일에 두는 것이 좋다고 생각합니다. (논의된 내용, 써 주신 내용과 일치)

배경

헥사고날 아키텍처의 적용 이유 중 일부
Repository 포트 및 어댑터 구조는 외부 인프라스트럭처로부터 우리 애플리케이션 개발의 영향을 최소화하기 위해 적용하고 있습니다.
따라서 JPA 등 인프라스트럭처에 대응하기 위한 추가 기능은, 관련 영역에 응집도 있게 구성하는 것을 지향합니다.

덧붙이자면 지금 진도에 포함되어 있지는 않지만, 곧 적용할 멀티모듈 프로젝트에서는 SpringBootApplication이 존재하는 모듈에 명시적으로 JPA 의존성을 추가하지 않을 수 있습니다. (특정 어댑터 모듈로부터 번들로 받아서 사용하는 것을 제안하려고 계획하고 있습니다.)

즉, 멀티모듈 프로젝트에서 모듈 간 종속성 관리를 하다 보면 진단될 내용이기도 했습니다.

이상의 이유로 JPA에서 응집도 있는 관리를 하기 위해, JPA Config 파일에 위치시키는 것이 좋아 보입니다.

JPA 관련 공통 기능(코어 기능)의 패키지 제안

선택지

• common 패키지
• Nettee JPA core 패키지

단일 모듈 프로젝트에서 고전적으로 common 영역에 두던 것들이 많습니다.
이 관례에 따라 common 패키지에 두는 것도 일차적으로 고려할 수 있습니다.

멀티모듈 프로젝트에서는 common 모듈에 common 패키지를 관리할 수 있습니다.
common 모듈에 불필요한 종속성을 제거하는 것은 멀티모듈 프로젝트 운용에서 주요 공통 작업 중 하나입니다.

이를 위해 저는 관련 특정 기술이나 특정 기능 단위 core 모듈을 만들어 관리하는 것을 제안하는 편입니다.
이때는 common 모듈과 구분하여 JPA 코어 패키지를 관리할 수 있습니다.

이상에서 언급된 패키지 선택지는 다음과 같습니다.

• me.nettee.common.jpa.config (common 관리 시)
• me.nettee.core.jpa.config (core 관리 시)
• me.nettee.jpa.config (core 관리 시)

개인적인 기호 및 안전장치로 멀티모듈 프로젝트에서는 일정 모듈그룹마다 베이스 패키지를 두어 다른 모듈의 베이스 패키지와 구분하고 있습니다.
또, 일각에서 최상위 도메인이 겹칠 일이 없다는 점으로, 패키지 이름이 한 뎁스만 줄어도 보기 편한 점을 제시합니다.

저는 이 새로운 주장들에 타당성을 느끼고 다음처럼 제안합니다. (core 패키지에 두기로 정한다면.)

• 멀티모듈 프로젝트에서: nettee.jpa를 베이스 패키지로 사용하고, nettee.jpa.config 및 nettee.jpa.support 등 패키지를 추가합니다.
• 단일모듈 프로젝트에서: me.nettee.core.jpa 패키지로 사용하고, me.nettee.core.jpa.config 패키지에 JpaConfig를 추가합니다.

[sweetykr7]

@taewookimm 님의 @CreatedDate, @LastModifiedDate 고찰에 대해서 잘 보았습니다.
또한 @merge-simpson 님이 제안해 주신 내용도 읽어보았습니다.

1.@EnableJpaAuditing으로 자동 관리
엔티티 생성·수정 시간을 자동으로 넣어주니 편리하고, 실수를 줄여줄 수 있어 좋은것 같습니다.
다만, 나중에 다른 ORM이나 DB로 갈아탈 때 작업이 늘어날 수 있지 않나 싶습니다.

2.직접 날짜 필드를 세팅
특정 라이브러리나 프레임워크 의존도를 낮출 수 있어 유연하지만,
엔티티나 서비스 로직 곳곳에서 직접 시간을 넣어줘야 하니 코드가 중복되거나 문제가 발생할 여지가 있을것 같습니다.

1번 방식 예시 : 생성, 수정 시간을 자동으로 넣어줍니다.

@Entity
public class ExampleEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @CreatedDate // JPA가 자동으로 생성 시간 관리
    private LocalDateTime createdAt;

    @LastModifiedDate // JPA가 자동으로 수정 시간 관리
    private LocalDateTime updatedAt;

    private String name;
}

2번 방식 예시 : 유연하지만 간혹 코드가 중복되거나 오류가 발생할 상황이 나타날 수 있을 것 같습니다.

@Service
public class ExampleService {
    private final ExampleRepository exampleRepository;

    public ExampleService(ExampleRepository exampleRepository) {
        this.exampleRepository = exampleRepository;
    }

    public ExampleEntity updateExample(Long id, String newName) {
        ExampleEntity entity = exampleRepository.findById(id)
                .orElseThrow(() -> new IllegalArgumentException("Entity not found"));

        // 수정 시 시간 갱신
        entity.setName(newName);
        entity.setUpdatedAt(LocalDateTime.now());
        return exampleRepository.save(entity);
    }
}

JPA 관련 공통 기능(코어 기능)의 패키지 제안부분은 좀 헷갈려서 다시 확인해보도록 하겠습니다.

[silberbullet]

@merge-simpson 님이 제안 주신 core 패키지 추가의 타당성을 느낍니다.

@taewookimm 님이 말씀해주신 것처럼 JPA에 종속될 이유가 없습니다. 앞선 설명은 @merge-simpson 님께 해주셨는데, 추가적인 의견을 제시합니다.

---

🚀 core.jpa 패키지는 엔티티가 @EnableJpaAuditing을 선택적으로 응용할 수 있도록 구성하기

@EnableJpaAuditing 의 큰 사용 이유는 자동으로 엔티티의 생성, 수정 시간을 JPA에게 위임하기 위해 사용한다고 생각합니다.

그렇지만 모든 엔티티가 꼭 생성, 수정 시간이 필요할까요? 예를 들어, 블로그 글의 Tag(태그) 목록들은 생성, 수정 시간이 불필요한 정보이기도 합니다. 단순 해당 글의 참조 용도로 사용되는 정보성 데이터 라면 생성 이후, 수정이 일어나기도 쉽지 않습니다.

그렇기에 하기와 같은 상위 클래스를 제안 드립니다.

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class BaseTimeEntity {

    @CreatedDate
    @Column(name = "created_at")
    private Instant createdAt;

    @LastModifiedDate
    @Column(name = "updated_at")
    private Instant updatedAt;
    }
}

• @MappedSuperclass 를 사용함으로써, 해당 클래스를 상속 받은 엔티티는 JPA 속성 매핑을 할 수 있도록 해줍니다.
• @EntityListeners(AuditingEntityListener.class) 는 @EnableJpaAuditing 이 적용된 환경에서 특정 엔티티에 Auditing 기능을 제공합니다.
• 무엇보다 abstract 를 선언하여 해당 클래스가 추상클래스로써, 개발자가 독단적으로 new BaseTimeEntity ()를 하지 못하도록 방지합니다.

[shin-jingyu]

@merge-simpson 님과 @silberbullet 님께서 제안하신 @CreatedDate와 @LastModifiedDate를 사용하는 방향이 적합하다고 생각됩니다.

추가 내용 보충입니다!

@EnableJpaAuditing과 @EntityListeners(AuditingEntityListener.class) 는 모두 Auditing 기능을 활성화하는 데 사용됩니다.
다만, 적용 범위에서 차이가 있습니다

• @EnableJpaAuditing: 프로젝트 전역에서 Auditing 기능을 활성화합니다.
• @EntityListeners(AuditingEntityListener.class): 특정 엔티티 클래스 내에서만 Auditing 기능을 활성화합니다.

[taewookimm]

@merge-simpson 님, @sweetykr7 님, @silberbullet 님, @shin-jingyu 님 소중한 의견 정말 감사드립니다!

우선 @sweetykr7 님께서 남겨주신 의견 잘 확인했습니다. 저 역시 고민했던 당시 JPA 관련 공통 기능 처리, 특히 멀티 모듈에서의 처리 방식에 접근하는 데에 있어 어려움이 있었습니다! 또한, 1번과 2번의 장점 단점이 명확했고, 어떤 방식으로 가야 할지 판단이 잘 서지 않았습니다. 그래서 저도 다시 한번 고민해 보고, JPA 응집도, 멀티 모듈의 관리 측면에서 더 생각해 봐야 할 것 같습니다.

@merge-simpson 님께서 제안해 주신 코어 기능의 패키지 방식 의견 확인했습니다.
common 모듈에 불필요한 종속성의 제거 목적과 JPA에서 응집도 있는 관리를 위한 JpaConfig 방식은 저 역시 납득이 됩니다.

추가로 @silberbullet 님께서 제안 주신 내용 중 "모든 엔티티가 꼭 생성, 수정 시간이 필요할까"의 내용도 한번 생각해 볼 내용인 것 같습니다.

저 역시 생각해 봤을 때 단순 참조 용도로만 사용되는 정보성 데이터가 수정이 되는 상황이 많지 않을 거라는 판단입니다.
그렇기에 @merge-simpson 님께서 제안 주신 패키지 방식과 제안 주신 상위 클래스의 의견은 너무 좋은 의견이었고, 도움이 많이 될 거라 생각됩니다.

@shin-jingyu 님께서 @CreatedDate, @LastModifiedDate를 사용하는 방향이 적합하다고 생각 주셨습니다!
저도 팀원들의 의견을 보고 고민해 보니 말씀 주신 방향이 더욱 적합하다고 생각됩니다!
추가 내용 보충 사항도 확인했습니다! @EnableJpaAuditing과 @EntityListeners(AuditingEntityListener.class)의 적용 범위에 대해 계속 헷갈렸던 부분이 있었고, 개념적으로 잘 몰랐던 부분도 있었는데 더욱 명확해진 것 같습니다! 감사합니다!

저 또한 다른 방식도 고민해 보고 리서치를 해보겠습니다! 더욱 좋은 의견이 생긴다면 해당 이슈에 남기도록 하겠습니다!

[merge-simpson]

@silberbullet 님께서 좋은 제안을 주셔서, 예전에 구두로 논의된 내용을 다시 언급해 보려고 합니다! 🚀
다들 활발한 논의 감사드립니다. 👍

---

💊 BoardEntity ➡ BaseTimeEntity ➡ BaseEntity 구조 (Extends ➡)

코드 리뷰에 추가해 드리려고 했는데 마침 논의된 김에 이슈에서 정리한 후, 코드 리뷰에 전달하는 것도 좋아 보입니다.

ID용 BaseEntity와 시간 타입 필드용 BaseTimeEntity의 상속 관계 맺기

당시 다음과 같은 상속 방식을 제안했습니다.

편의성을 생각하면 다음 중 택 1이 까다로운 고민거리이기 때문이었습니다.

• ID는 거의 필수 컬럼으로 취급되므로 공통으로 관리하는 것이 좋지만, 스키마와 엔티티에 따라 타입을 다르게 사용합니다.
  (BaseEntity, UuidBaseEntity, SnowflakeBaseEntity 등)
• 시간 타입들은 타입이 일관되어 동일한 수퍼클래스로 관리하기 좋지만, 선택적인 컬럼입니다. (BaseTimeEntity)

따라서 상속 관계를 한 계보 추가할 수 있는 전략을 택했습니다.

🌱 상속 관계

• BaseTimeEntity는 BaseEntity를 상속받습니다.
• UuidBaseTimeEntity는 UuidBaseEntity를 상속받습니다.

🌱 Examples of BaseEntity

ID Type	ID Only	With Time
Long	BaseEntity	BaseTimeEntity
UUID	UuidBaseEntity	UuidBaseTimeEntity
(Independent Management)	(none)	CommonBaseTimeEntity

예시: Long ID를 관리하는 수퍼 클래스들

Long ID를 관리하는 예시를 보면 다음과 같습니다.

• BaseEntity: Long ID만 관리 시 상속
• BaseTimeEntity: Long ID 및 시간 타입 필드 관리 시 상속

이하 예시 링크의 출처는 이곳을 참고해 주세요.

BaesEntity (using Long ID)

Imports

import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
import jakarta.persistence.MappedSuperclass;

import java.io.Serializable;

@MappedSuperclass
public abstract class BaseEntity implements Serializable {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    public Long getId() {
        return id;
    }
}

BaseTimeEntity (using Long ID)

Imports

import jakarta.persistence.EntityListeners;
import jakarta.persistence.MappedSuperclass;
import org.springframework.data.annotation.CreatedDate;
import org.springframework.data.annotation.LastModifiedDate;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

import java.time.Instant;

@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class BaseTimeEntity extends BaseEntity {
    @CreatedDate
    private Instant createdAt;
    @LastModifiedDate
    private Instant updatedAt;

    public Instant getCreatedAt() {
        return createdAt;
    }

    public Instant getUpdatedAt() {
        return updatedAt;
    }
}

---

🚀	이 코멘트는 새 이슈로 전달되었습니다. Referring discussion: Core: JPA BaseEntity류 추상 클래스 관리 #28

[merge-simpson]

Discussion으로서는 완료된 것으로 생각하여 이슈 종료

작업은 아직 병합되기 전이지만, 이 이슈는 discussion 이슈이므로, 일차적으로 종료하겠습니다!

좋은 논의로 멤버들과 많은 생각을 할 수 있게 이슈를 열어 주신 @taewookimm 님, 감사드립니다!

논의에 열심히 참여해 주신 @sweetykr7 님, @silberbullet 님, @shin-jingyu 님도 정말 감사드립니다! 👍 💯

팀이 활성화되는 것이 한 눈에 보여서 너무 기쁩니다!