스프링 빌더, 엔티티

해당 포스트는 인프런의 Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트 강의의 도움을 받았습니다

Builder

빌더 패턴은 객체의 생성자를 한 가지로 줄일 수 있도록 하는 디자인 패턴입니다.

객체의 생성자가 지나치게 많아지는 것을 예방할 수 있습니다.

@Builder 애노테이션을 붙여 사용할 수 있습니다.

@Builder
@AllArgsConstructor
class User {
...
}

User user = new User()
	.builder()
    .username("...")
    .email("...")
    ...

필요한 파라미터를 누락하는 경우 컴파일타임에 확인할 수 없게 되어 디버깅이 어려워진다는 단점이 있습니다.

엔티티

도메인 엔티티와 DB 엔티티는 다른 것입니다.

도메인 엔티티는 JPA와 관계가 없는 것입니다.

도메인 엔티티는 객체로서 존재하고, DB 엔티티는 데이터베이스 세계에서 이미 존재하던 개념으로 테이블에 해당합니다.

둘 사이의 개념적 차이가 발생하므로 이를 연결해주기 위해 영속성 객체를 사용하는 것입니다.

이때 도메인 엔티티와 영속성 객체를 일치시켜 생각할 수도 있지만, (도메인 엔티티에 @Entity를 붙일 수도 있지만) 이것은 좋은 설계가 아닙니다.

도메인 엔티티에 JPA를 붙이게 되면 서비스가 RDB에 종속적이어지기 때문입니다.

mongoDB와 같은 Document DB는 JPA에서 구현된 개념과 차이가 있어 JPA를 사용하지 않기 때문입니다.

질문하기

1. Builder는 컴파일타임에 오류를 캐치할 수 없는 이유가 뭘까요?