본문 바로가기

Backend/질문 시리즈

[질문-시리즈] Validate! 유효성 검사는 어디에서 해야할까?

[질문 시리즈]는 주변 개발자 분들께 제가 생각하는 내용을 질문 후 답변받은 내용입니다.
답변엔 여러 사람들의 관점이 섞여있어 최대한 정리하여 작성하였습니다.
해당 포스팅은 질문에 대한 정답을 명확히 하는 것이 목표가 아닙니다.
프로젝트를 바라보는 관점에 따라 의견이 다양해질 수 있고, 이 글 또한 그중 하나의 관점 정도로 생각하고 읽어주세요.
주의!
이번 [질문-시리즈]에는 정해진 답변이 없습니다.
제 주관적인 관점만 가득히 담겨있으니 좋은 답변이 있다면 댓글로 이야기를 해보면 좋을 것 같습니다.

질문: Validate! 유효성 검사는 어디서 해야할까요?

Data의 유효성 검사는 어디에서 진행하는 것이 맞을까요? Controller? Service? domain?

이전 포스트에서 Data의 유효성 검사의 주체 Data 자신인지 외부의 객체인지에 대한 내용을 주제로 TDA(Tell Don't Ask)를 작성하였습니다.

답변은 Data는 단순 정보에 불과하므로 Validator에게 유효성검사의 책임을 넘기는 게 좋을 것 같다. 였습니다.

그 당시에는 그렇구나~ 싶은 정도에 끝났는데, 지금 다시 생각해 보면 책임이라는 말이 왜 나왔을까 라는 고민이 들었습니다.

더 나아가서 유효성 검사에 대한 책임이 필요하다면, 유효성 검사에 대한 니즈는 어디서 왔을까?입니다.

 

이를 설명하기 위해 예시를 보여드리려 합니다.

 

[전제]

- 회원과 포인트에 대한 도메인은 구분되어 있습니다.

[요구사항]

- 포인트 지급 기능

  • 회원 아이디는 필수로 전달받아야 한다.
  • 포인트는 필수로 전달받아야 한다.
  • 회원이 포인트를 지급받을 수 있는 상태(normal, block)에만 지급해야 한다.
  • 포인트는 한 번에 100~10000 범위 내만 지급 가능하다.

[포인트 지급] 요구사항을 해결하기 위해 4개의 비즈니스 로직으로 구분하였습니다.

  1. 전달받은 회원 아이디가 null인지 검사한다.
  2. 회원 아이디를 기준으로 회원을 조회 후 상태가 Normal인지 검사한다.
  3. 포인트가 null인지 and 100~10000 범위 내인지 검사한다.
  4. 포인트 지급에 대한 정보를 저장한다.

주어진 상황에서 [유효성검사에 대한 책임은 어디 있는가?]를 고민해 봅시다.

[포인트 지급] 요구사항을 처리하고 있으므로 해당 도메인 로직은 [포인트]에 위치합니다.

해당 로직 과정에서 회원 정보를 관리하는 [회원 도메인]에게 [회원 상태가 어때?]라는 질문을 해야 합니다.

 

여기서 고민할 것은 [회원 아이디가 null인지 검사][회원 상태가 어때?] 요청 전에 해야 할까요?

아니면 [회원 상태가 어때?] 내부에서 해야 할까요?

 

마이크로서비스 단위를 기준으로 [회원 상태가 어때?]라는 로직은 다양한 도메인에서 접근할 것입니다.

이런 상황에서 [회원 아이디가 null인지 검사]를 모든 서비스에서 진행해야 할까요?

[회원 상태가 어때?] 기능은 다른 도메인이 자신을 어떻게 사용할지 모릅니다.

[회원 상태가 어때?] 기능은 자신의 역할을 위해 전달받은 파라미터(회원 아이디)정상적인지 확인하고 이후 회원상태를 조회하여 결과를 반환하는 것이 적합하다 생각합니다. (회원 아이디가 정상적이지 않는다면 예외처리를 진행할 것입니다.)

 

[회원 도메인]은 회원 상태정보를 제공하는 도메인 로직이 필요하고, 동작에 필요한 책임은 [회원 도메인]이 갖고 있어야 합니다.

 

[총정리]

제가 생각하는 유효성 검사의 위치전달받은 파라미터를 직접적으로 다루어야 하는 영역입니다.

 

API Spec을 고려하면 파라미터의 유효성 검사는 Controller에서 진행하는 것이 맞지 않을까요?

오늘의 주제와 관련된 대화를 나누던 중 받았던 질문입니다.

아쉽게도 질문받은 내용에 대해 듣고선 "아차 그런가!"라고 생각하다 보니 질문에 대한 답변을 드리지 못했습니다.

지금 질문을 다시 듣게 된다면, 보다 나은 답변을 위해 API Spec은 무엇인가?를 질문할 것 같습니다.

API SpecAPI 명세를 말하는 것이라 생각하면 어째서 API Spec을 위해 파라미터 유효성 검사Controller에서 해야 할까요?

 

API Docs를 작성할 때 API에게 전달할 값은 무엇이고 어떠한 제한이 있는지 설명해서?

API Spec을 Controller의 형상과 동일하게 고려하고 개발을 한다면 Controller에 두어도 괜찮을 것인가?

API 명세서를 참고할 사람은 누구인지? Controller의 코드를 참고하는 사람인가? 별도의 문서는 없는 것인가?

 

좀 더 질문과 관련된 이야기를 하고 싶지만 제가 이해한 정보가 없다 보니 아쉽게도 결론이 나지 않았습니다.

정답은 많고 상황에 따라 최선의 정답이 있다 생각합니다.

이번 질문도 분명 알맞은 상황이 있을 것 같은데 이와 같은 개발 및 경험이 있으신 분들은 조금이나마 공유해 주시면 감사합니다!