You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
도메인에서의 null 검증 어떻게 하는 것이 좋을까? @NotNull vs @column(nullable=false)
1️⃣ 처음에 갖고 있던 생각
도메인은 최소한의 의존성만 가져가고 가능한 순수하게 유지되어야 한다. 따라서 도메인의 값이 초기화 될 때 null 검증 로직을 직접 작성하여 애플리케이션 단에서 한 번 검증하고 @Column(nullable=false)를 추가해 DB 단에서도 null을 검증할 수 있도록 추가하는 것이 좋다.
만약 @NotNull을 사용하게 된다면 Bean validation 의존성을 추가해야 할텐데 null 검증 때문에 validation 의존성을 추가하는 것은 도메인의 외부 의존성만 늘리는 것이라고 생각한다.
2️⃣ 두 번째 생각
기존에는 도메인을 최대한 외부에서 격리시켜서 순수하게 가져가야 한다는 생각이었다. 그런데 @NotNull을 사용하자는 입장에 설득(?) 당해버렸다.
@NotNull을 엔티티에 붙이면 Application과 DB 단에서 모두 null 검증을 할 수 있다고 한다. 애플리케이션에서 null 검증을 해주는 건 아는데 어떻게 DB까지...? 알고보니 jpa 속성 중 ddl-auto=create로 되어있으면 테이블 생성 시 @NotNull이 붙어있는 컬럼에 not null이 붙어서 생성된다. 이번에 찾아보면서 처음 알게 된 사실이다!🤩
무조건 @NotNull을 사용하자는 입장은 아니고 만약 DTO 검증이나 다른 이유로 Bean validation 의존성이 이미 추가되어있는 상태라면, @NotNull을 활용하자는 것이다.
도메인에서의 null 검증 어떻게 하는 것이 좋을까? @NotNull vs @column(nullable=false)
1️⃣ 처음에 갖고 있던 생각
도메인은 최소한의 의존성만 가져가고 가능한 순수하게 유지되어야 한다. 따라서 도메인의 값이 초기화 될 때 null 검증 로직을 직접 작성하여 애플리케이션 단에서 한 번 검증하고
@Column(nullable=false)
를 추가해 DB 단에서도 null을 검증할 수 있도록 추가하는 것이 좋다.만약
@NotNull
을 사용하게 된다면 Bean validation 의존성을 추가해야 할텐데 null 검증 때문에 validation 의존성을 추가하는 것은 도메인의 외부 의존성만 늘리는 것이라고 생각한다.2️⃣ 두 번째 생각
기존에는 도메인을 최대한 외부에서 격리시켜서 순수하게 가져가야 한다는 생각이었다. 그런데
@NotNull
을 사용하자는 입장에 설득(?) 당해버렸다.@NotNull
을 엔티티에 붙이면 Application과 DB 단에서 모두 null 검증을 할 수 있다고 한다. 애플리케이션에서 null 검증을 해주는 건 아는데 어떻게 DB까지...? 알고보니 jpa 속성 중ddl-auto=create
로 되어있으면 테이블 생성 시@NotNull
이 붙어있는 컬럼에 not null이 붙어서 생성된다. 이번에 찾아보면서 처음 알게 된 사실이다!🤩무조건
@NotNull
을 사용하자는 입장은 아니고 만약 DTO 검증이나 다른 이유로 Bean validation 의존성이 이미 추가되어있는 상태라면,@NotNull
을 활용하자는 것이다.나를 설득시킨 참고자료들
The text was updated successfully, but these errors were encountered: