그러면 나오는 의문점이 모델 객체에 담아서 쓰느냐

서비스로직에 쓰느냐 이건데,

서비스로직은 각각의 비즈니스 로직이 특화되었을 떄 사용하는게 맞고

이걸 중복 로직으로 썼을 때 위 부분에 대해 정의 표현이 안 좋은 점이 있음

repository에서 쓰는 방법은 data랑 연관된 부분에 대한 검증은 나쁘지 않을 수도 있는데

validation 일반 검증이랑 다른 위치에 있어서 현실적으로 생각하는 인식과는 다르다는 문제가 생김

model에서 각각 검증을 따로 하는게 정답이 맞는듯 이 경우 기존 검증과 같은 곳에서 지킨다는 장점이 있고

물론 이중 바뀔 여지가 없고 명확한 부분의 로직에 대해서는 composite로 표현하는게 맞음

(디미터급으로 너무 은닉화만 쓰지않으면 되는거기도 하고, 너무 많지않다면 구분안하는게 맞을 수도 있고 취사)