[개발 일기] 2025.06.03 - 값 검증을 응용 계층에서??

💡 개요

 

나는 값 검증을 주로 도메인 영역에서 수행한다.

 

 

그 이유는, 그렇게 하는 것이 응집도가 더 높다고 생각하기 때문이다.

 

 

실제 도메인의 값 검증에는 여러 값이 사용되는 데, 이를 모두 응용 계층에서 검증하면 각 값에 대한 책임이 분산되어 응집도가 떨어질 수 있다고 생각한다.

 

 

그래서 나는 값 객체가 생성될 때, 즉 도메인 계층에서 검증을 수행하는 편이다.

 

 

그런데 “DDD 도메인 주도 설계”의 221쪽에선 응용계층에서 하는 게 맞다고 설명한다..

 

 

뭐가 맞을까..

 

 

 

✅ 도메인 계층에서 검증

 

도메인에서 값 검증을 한다는 것은 값 객체(Value Object)나 엔티티(Entity)가 생성될 때 유효성 검사를 수행한다는 것이다.

 

 

👍 장점

• 응집도 높음: 값과 검증 로직이 함께 존재하므로 변경 시 일관성 유지가 쉬움 (내가 생각하는 가장 중요한 이유!!)
• 도메인 규칙의 명시적 표현: "이 값은 항상 이렇게 유효해야 한다"는 의도를 코드에 녹일 수 있음
• 재사용성 증가: 같은 값 객체를 여러 서비스에서 사용해도 검증이 중복되지 않음
• 불변성과 안정성 보장: 단순히 사용자의 요청에 대한 값 객체 검증 뿐만 아니라, 서비스 내부에서 사용되는 객체의 검증까지 진행하기 때문에 더 신뢰도 높은 서비스를 운영할 수 있음

 

 

👎 단점

• 단순 입력 검증에는 과함: 예를 들어 단순히 "null이 아니어야 함" 같은 검증까지 도메인에 넣으면 무겁게 느껴질 수 있음
• 에러 처리 복잡도 증가: 도메인 내부에서 발생한 예외를 응용 계층에서 적절히 핸들링하려면 번거로움이 있음

 

 

 

✅ 응용 계층에서 검증

 

Service 계층에서 DTO 값을 검사하고, 그 후 도메인 객체 생성하는 방식을 의미한다.

 

 

👍 장점

• 입력 흐름 제어가 명확함: 어떤 값이 들어오고 어떤 검증을 거쳐 도메인으로 넘어가는지 한눈에 보임
• 예외 처리 간편: 사용자에게 메시지를 리턴하거나 400 Bad Request 등을 쉽게 만들 수 있음
• 검증 도구 활용 쉬움: @Valid 와 같이 프레임워크의 검증 기능과 쉽게 연동됨

 

👎 단점

• 응집도 낮음: 검증과 값 정의가 분리돼 있어 변경 시 실수할 여지가 있음
• 중복 가능성: 여러 서비스에서 같은 검증을 반복해야 할 수도 있음
• 불완전한 도메인 보호: 응용 계층에서 빠져나온 잘못된 값이 도메인으로 들어갈 수 있음 (검증 누락 시 치명적)

 

 

 

🤔 결론

 

물론 응용 계층에서 값 검증을 진행하는 것에 대한 장점도 존재한다.

 

 

하지만 난 웬만하면 도메인에서 검증하는 방식을 선호한다..