JPA Entity 생성자에 자동 관리 필드를 넣어야 하는가 Should JPA Entity Constructors Include Auto-Managed Fields?

@Entity
public class User {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @CreatedDate
    private LocalDateTime createdAt;
    
    @LastModifiedDate
    private LocalDateTime updatedAt;
    
    private String name;
    private String email;
    
    // I stop here. How should I design the constructor?
}

In development, sometimes seemingly trivial decisions can become major issues later. Designing JPA Entity constructors is one of them. Particularly, whether to include auto-generated fields like @GeneratedValue id or audit fields like @CreatedDate and @LastModifiedDate as constructor parameters is a more complex problem than it initially appears.

At first, I thought it was simple. Create a constructor that accepts all fields - you can create complete objects and testing is easy. It seemed like the most object-oriented approach. But in practice, I found problems. When developers put arbitrary values in id, it conflicts with JPA’s @GeneratedValue strategy, and putting incorrect timestamps in audit fields breaks data integrity.

But removing auto-managed fields from constructors creates other concerns. The Entity class seemed too dependent on JPA. Every time I wrote new User("John Doe", "john@example.com"), I thought “this object isn’t complete without JPA.” It felt awkward for something that should be a pure domain object.

Of course, nowadays there are attempts to view even JPA Entities as infrastructure and completely separate ‘pure’ domain objects from JPA Entities. But that seems excessive. JPA/Hibernate was originally designed to be POJO-based, with the intent that domain objects containing business logic would simultaneously serve as persistence objects. Rather than creating another mapping layer, I thought it would be better to find a reasonable compromise. This led me to ponder how to resolve this dilemma.

Practical Options

Option 1: Only Business Fields in Constructor

@Entity
public class User {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @CreatedDate
    private LocalDateTime createdAt;
    
    @LastModifiedDate
    private LocalDateTime updatedAt;
    
    private String name;
    private String email;
    
    public User(String name, String email) {
        this.name = name;
        this.email = email;
    }
    
    protected User() {} // JPA default constructor
}

Clean. The intent is clear. It conveys the message: “These fields are managed by JPA, so don’t worry about them.”

However, it becomes a bit cumbersome when writing tests. When you need to create an entity with a specific ID, you have to use reflection or create separate factory methods.

Option 2: All Fields in Constructor

public User(Long id, String name, String email, 
           LocalDateTime createdAt, LocalDateTime updatedAt) {
    this.id = id;
    this.name = name;
    this.email = email;
    this.createdAt = createdAt;
    this.updatedAt = updatedAt;
}

Testing is convenient. Creating mock data is simple. But the problems with this approach quickly become apparent in practice.

Too many parameters. Especially when more audit fields are added (createdBy, updatedBy, etc.), the constructor becomes a monster. Developers must constantly think: new User(null, "John Doe", "john@example.com", null, null) - “remember to put null for the first and last two.” Even knowing they’re auto-managed fields, having to explicitly write null every time is cumbersome, and accidentally putting values can conflict with JPA’s auto-management features or behave unexpectedly.

Option 3: Constructor Overloading

// For business use
public User(String name, String email) {
    this.name = name;
    this.email = email;
}

// For testing
User(Long id, String name, String email, LocalDateTime createdAt) {
    this.id = id;
    this.name = name;
    this.email = email;
    this.createdAt = createdAt;
}

Creating a package-level constructor for testing. Not bad, but having multiple constructors can be confusing about which one to use. Especially for new developers. I’ve seen cases where teams use UUID as the Primary Key to avoid this problem entirely. Since the ID is determined at object creation time, it’s clean. But introducing UUID just to solve constructor design issues seems excessive.

The Test Problem Can Be Solved

The biggest obstacle when choosing Option 1 is testing. But this problem is definitely solvable. You might think “Why not just use @DataJpaTest?” But even though it’s a slice test, it’s still an integration test. Unit tests for domain models don’t always need to depend on the Spring container. For fast and lightweight unit tests, we need other approaches.

Using ReflectionTestUtils

@Test
void testUserQuery() {
    User user = new User("John Doe", "john@example.com");
    ReflectionTestUtils.setField(user, "id", 1L);
    
    // Continue with test...
}

Using ReflectionTestUtils provided by Spring Test makes it simple. It hides the complexity of reflection and provides a clean API.

For a more systematic approach, you could create a builder class that exists only in the test package. It’s a decent method as it doesn’t touch production code while being convenient for tests.

// Exists only in src/test/java package
public class UserTestBuilder {
    private Long id = 1L;
    private String name = "Test User";
    private String email = "test@example.com";
    private LocalDateTime createdAt = LocalDateTime.now();
    
    public UserTestBuilder id(Long id) {
        this.id = id;
        return this;
    }
    
    public UserTestBuilder name(String name) {
        this.name = name;
        return this;
    }
    
    public User build() {
        User user = new User(name, email);
        ReflectionTestUtils.setField(user, "id", id);
        ReflectionTestUtils.setField(user, "createdAt", createdAt);
        return user;
    }
}

Which Choice to Make?

There’s no perfect answer, and different teams will make different choices based on their preferences. Personally, I’ve come to prefer the approach of including only business fields in constructors. While it’s a clear disadvantage that testing becomes more complex, it can be adequately resolved with methods like ReflectionTestUtils or test builders introduced above.

Of course, I’ve seen many projects make different choices. Some teams prioritize testing convenience and create constructors that accept all fields, while others compromise with package-level constructors. Whatever choice you make, it’s more important to establish and maintain consistent standards within the team. Ultimately, code is read by people, and I believe good code is code that clearly conveys its intent.