인프런 커뮤니티 질문&답변
작성한 질문수
도메인 모델에서의 검증과 애플리케이션 레벨 검증의 경계
작성
·
189
5
도메인 모델에서의 검증과 애플리케이션 레벨 검증의 경계에 대해 질문드립니다.
현재 도메인 모델에서는 이메일 형식이 올바른지, 닉네임이나 비밀번호가 null이 아닌지 같은 최소한의 조건만 검증하고 있습니다.
반면, 비밀번호가 8자 이상인지, 닉네임이 5자 이상인지 같은 검증은 애플리케이션 레이어에서 처리하고 있습니다.
그런데 닉네임이 5자 이상이어야 한다 같은 규칙도 도메인 규칙으로 볼 수 있지 않을까 라고 생각이 들어 해당 검증 역시 도메인 모델에서 처리하는게 맞지 않나 라는 생각이 드는데,
도메인 모델에서의 검증과 애플리케이션 레벨 검증의 경계는 어디까지 두는 게 좋은지 토비님 의견이 궁금합니다.
말씀하신것을 토대로 예측해 봤을때 형식이나 정책적 요구사항(변경 가능성이 있는 규칙)은 애플리케이션 레이어에서, 도메인의 본질적 불변 조건은 도메인에서 검증하는 걸까요?
답변 2
6
좋은 질문해주셔서 감사합니다.
이것도 제가 개발팀과 자주 하는 이야기입니다. 어떤 경우엔 도메인쪽에 상세한 검증 규칙을 다 넣기도 합니다. 특히 자리수 같은 것들도 체크를 하죠. 그러면 애플리케이션 서비스, 심지어는 앞의 API에서는 체크하지 않아도 되나요. 혹은 체크가 여러번 중복되는데 이게 좋은 것인가요라는 질문을 할 수 있겠죠.
이번 강의 코드를 만들면서 우리 스프런 개발팀에서는 이런 이야기를 했습니다(물론 가상입니다). 도메인 모델을 만들 때 닉네임의 최소 자리수, 최대 자리수, 허용 문자열(영문과 숫자만 허용)과 같은 것들을 이야기하던가요? 그럴 수도 있고 아닐 수도 있다는 생각이 들었습니다. 이메일은 메일 주소 형식을 지켜야 한다라는 것은 이메일이라는 언어를 사용할 때 본질적으로 녹아져 있다고 봅니다. 그러니 도메인에서 체크할 필요가 있겠죠. 그런데 닉네임이 최소 4자리, 이건 도메인의 본질적인 속성인가 라고 물었을 때, 100% 그렇다고 답을 하지는 못했습니다. 회원의 닉네임은 필수이다까지죠.
그래서 이번 개발의 정책에서 도메인 클래스에서는 금액, 수치와 같은 불변식을 지켜야 하는 경우가 아니라면, 단순 문자열의 길이 등을 직접 체크하지는 말자. 그건 애플리케이션 또는 UI(API) 로직이다라고요. 그래서 그건 앞의 애플리케이션 서비스 쪽에서 표준 빈 벨리데이션 애노테이션과 스프링의 @Validated 지원 기능을 이용해서 처리하게 했습니다. 사실은 API 레벨에서 먼저 이 빈 검증 기능을 이용해서 자리수 등을 체크할 겁니다.
그럼 그 외의 경로로 회원이 만들어지는, 도메인 클래스만 사용되는 경우엔 어떻게할 것인가라고 하실 수도 있겠죠. 예를 들어 배치 작업이나 마이그레이션 같은 것들이죠. 그래서 살짝 고민이 되네요. 하지만 아직 그쪽 개발을 하고 있지 않으니 일단은 위에서 이야기한 수준으로 개발을 먼저 진행하기로 했습니다.
나중에 도메인 엔티티를 사용할 때 좀 더 엄격한 검증 로직을 더해야한다라고 하면, 그때는 아마도 MemberValidator와 같은 분리된 도메인 서비스를 만들어서 사용할 것입니다. 그러면 자릿수 같은 속성을 스프링 부트 프로퍼티 등으로 분리시켜서 지정하게 만들 수도 있을 것이고요.
그래서 아직은 엔티티에선 필수 값이 들어왔는지 여부만 체크하는 것으로 만들었습니다.
이런 논의를 해볼 수 있어서 너무 즐겁네요. 정말 개발팀과 이야기를 나누는 것 같은 느낌입니다.
0
안녕하세요, 인프런 AI 인턴입니다. dlwogns3413님께서 주신 흥미로운 질문에 대해 답변드리겠습니다.
도메인 모델과 애플리케이션 레벨에서의 검증 경계에 대한 고민은 많은 개발자들이 공감하는 부분입니다. 도메인 모델에서의 검증과 애플리케이션 레벨 검증의 차이를 이해하는 것은 설계의 핵심적 요소 중 하나입니다.
도메인 모델 검증: 도메인 모델은 비즈니스 로직의 핵심 부분을 담당하며, 도메인의 본질적인 규칙과 불변조건을 책임집니다. 예를 들어, 이메일 형식이나 필수적인 속성(null이 아닌지 여부)에 대한 검증은 도메인 모델에서 처리하는 것이 일반적입니다. 이는 도메인의 상태를 항상 올바른 상태로 유지하도록 보장하는 역할을 합니다.
애플리케이션 레벨 검증: 애플리케이션 레벨에서는 도메인에 직접적으로 포함되지 않는 정책적이고 변경 가능성이 큰 검증을 처리합니다. 비밀번호의 길이 규칙이나 닉네임 길이 제한과 같은 검사는 비즈니스 요구사항에 따라 변할 수 있으므로, 애플리케이션 레이어에서 처리하는 것이 유연성을 제공합니다. 이러한 검사는 사용자 인터페이스에 더 가깝고, 도메인 모델에서는 덜 필수적인 요구사항으로 간주될 수 있습니다.
결과적으로, 닉네임이 5자 이상이어야 한다는 요구사항은 프로젝트의 특성과 팀의 컨벤션에 따라 도메인 또는 애플리케이션 레벨에서 처리할 수 있습니다. 그러나 일반적으로 본질적인 비즈니스 규칙은 도메인 모델에, 변동 가능성이 높은 규칙은 애플리케이션 레벨에 두는 것이 좋습니다.
관련된 더 깊이 있는 논의를 위해, 토비님의 기존 Q&A를 참고하시기 바랍니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.