인프런 커뮤니티 질문&답변

안녕하세요! 질문 감사드립니다!

먼저 현재 기준으로 보면 개념 객체로 변환하기 전에 기본적인 validation 은 Presentation Layer 에서 validation 처리 후 변환하여 개념 객체를 생성하고 있습니다
(가급적 최대한 완전한 개념객체를 생성하기 위해 객체를 만들때 부터 완전하게 잘 만들자를 위한 느낌이라고 보시면 됩니다 ReviewController.createReview 의 toTarget(), toContent() 참고)

다시 돌아와서 말씀해주신대로 개념 객체 자체적으로 validate 를 갖는 것은 크게 문제가 되지 않습니다!
다만 개념 객체가 생성되기 전 완결성을 갖고 생성 되는게 제일 좋다고 생각합니다

개념 객체는 단순히 값 객체는 아니긴합니다, 상황이 된다면 함수를 자연스럽게 추가해도 되는 클래스입니다 😄

예를들어 만약 개념객체가 생성 후 행위를 직접 처리해야하는 코드가 있다면 추가적인 validation 함수는 자연스럽게 생길 수 있을 것 같습니다!
ex) Order 객체가 돌아다니면서 상품 옵션 객체를 동적으로 수집하는 방식이라면..? 수집 후 validation 책임은 Order 개념 클래스 안에 넣을 수 있음
(다만 이번 강의에서 적절한 예제가 없었던 것 같은 느낌입니다!)

또 ReviewPolicyValidator 의 경우는 개념 객체만으로는 검증이 어렵고 디비의 데이터인 OrderItem 까지 조회를 해야하다보니 자연스럽게 도구가 생긴 것으로 봐주시면 좋을 것 같습니다!

모쪼록 답이 되었으면 좋겠습니다! 감사합니다!

안녕하세요, 인프런 AI 인턴입니다. 우으어으님.

개념을 표현하는 객체 내부에 검증 메서드를 두는 방식은 매우 유용한 설계 패턴 중 하나입니다. 해당 접근 방식은 특히 도메인 주도 설계(Domain-Driven Design, DDD)에서 자주 사용되며, 이를 통해 객체가 스스로 자신의 상태를 관리하고 책임질 수 있도록 합니다. 이를 ‘스마트 객체’라고 부르기도 하는데, 이는 객체가 단지 데이터를 보관하는 역할을 넘어서 비즈니스 로직도 포함할 수 있는 상태를 뜻합니다.

이러한 설계의 장점:
- 응집도 증가: 관련된 데이터와 로직이 한 곳에 모여 있으면 코드 유지 보수가 용이해지고, 버그 발생 가능성을 줄일 수 있습니다.
- 캡슐화: 객체 내부의 데이터가 잘 은닉되며, 객체 자신이 데이터를 검증하므로 잘못된 상태로의 전환을 예방할 수 있습니다.
- 유연성: 각 객체가 스스로 상태 검증을 수행함으로써, 개별 객체의 책임이 명확해지고 재사용성이 높아집니다.

그러나 이와 같은 방식이 모든 상황에 적합한 것은 아닙니다. 복합 검증이나 여러 객체들 간의 상호작용이 요구되는 경우, 검증 로직이 퍼져 산재될 위험이 있으며, 객체 간 결합도가 증가할 수 있습니다. 따라서, 검증 로직의 복잡도나 도메인 모델의 설계를 고려하여 최적의 분리를 고민해야 합니다.

이와 관련해서는 비즈니스 로직 및 도메인 관련 개념 설계의 중요성 에 대한 기존 답변을 참고하시면 도움이 될 것입니다. 이 링크를 통해 각 레이어별로 적절한 책임 분리와 설계 전략에 대해 더 많은 인사이트를 얻을 수 있습니다.

강의에서 추가적인 설명이 있을 수 있으니, 강의를 계속해서 시청하시며 더 많은 통찰을 얻으시기를 바랍니다. 수강 중 궁금한 점이 있으시면 언제든지 질문해 주세요. 곧 지식공유자께서도 자세한 답변을 주실 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.