오류 데이터가 DB에 저장되어 있는 경우 검증로직은 어떻게 해야 할까요?

Question

예를 들어 어떤 계정의 유효기간이 있고 시작일, 종료일이 있다고 할 때.. 당연히 시작일은 종료일보다 앞서야 하잖아요? 그래서 생성자나 setter 쪽에 '시작일 <= 종료일' 같은 조건을 넣었고 신규 객체를 생성할 때 잘 적용됩니다. 그런데 이제 외부 시스템에서 계정 정보를 마이그레이션받아야 하고 그쪽에서는 시작일, 종료일 선후 조건이 없어서 '시작일 > 종료일' 같은 데이터가 있다면(!!) 어떻게 처리해야 하는가..에서 고민이 있습니다.일단 저장은 한다? 아니면 거부하고 외부 시스템에 데이터 수정 요청을 한다?외부 시스템이 훨씬 더 거대하고 데이터가 함부로 건드리기 무서운(돈이 오가는..) 녀석이라면..?그렇다고 도메인의 로직을 위반하는 데이터를 받아서 오염시키는게 맞나..?'시작일 <= 종료일' 조건을 어느 시점에 적용해야 하는가?생성자나 setter에 넣어서 객체 생성이나 필드값이 바뀌는 시점에 바로 검증하는게 좋아보임그러나 위처럼 문제가 되는 데이터가 이미 들어와버린 경우 오류 수정을 위해 DB 조회 -> 객체 생성 시 바로 에러 발생별도의 메서드(User::validate 등)나 검증 서비스(UserValidationService)로 분리? 이러면 캡슐화가 깨지는 것인가?별거아닌데 귀찮은 고민이 생기더라구요 ㅠㅠ 구현하기 나름이겠지만 보통 이런 경우 데이터 모델에 저런 도메인 로직을 타이트하게 잡지 않고 그냥 값을 담는 용도로만 쓰나요? 지금 시스템 자체는 JPA를 쓰지만 클린아키텍처를 적용해보려고 별도의 도메인 모델이 있는 상태입니다.

basscraft · Answer

방대한 데이터를 이관해야 하는 경우 말씀하신 것 처럼 상식적인 규칙에 어긋나는 데이터가 유의미한 데이터냐 가베지로 보고 버릴 것 이냐는 쉬운 작업은 아닐 것 입니다.말씀하신 것 처럼 금융거래 같은 중요한 기록이라면 더더욱 신중해야 할 것 입니다.단순히 하나의 row별로 유의미한 히스토리 검증이 불가능한 경우 보통은 그냥 이관하고 후에 대책을 세우는 것이 맞을 것 같습니다.건수가 얼마나 되는지 모르겠지만 대량의 데이터를 건별로 검증을 하면서 이관하기에는 시간과 리소스가 생각하는 것 보다 상당히 많이 필요하고 이관 한 후에 발생하는 문제를 예측하기가 쉽지 않을 것 같습니다.

yeori · Answer

업무 맥락에 따라 대응이 다르겠지요.일단 넣어놓고 애플리케이션에서 처리하는 방식이 나은지,디비에 넣지 말고 버려도 되는지,데이터 생성 기관에 통보해서 바로 잡아야 하는지 등등...예전에 위도와 경도가 뒤바뀐 데이터들이 발견돼서 바로 잡은 적이 있는데, 이런거야 간단한 처리이고, 아예 엉터리 데이터인데 버리면 안되는 경우는 그쪽에 얘기해서 조치를 받든가 해야겠죠.

오류 데이터가 DB에 저장되어 있는 경우 검증로직은 어떻게 해야 할까요?

2개의 답변

#hexagonal 목록