의논 내용
- Entity 내부에 검증로직을 둘 것인가에 대하여
- DTO 작성에 Sealed interface + permitted sublcass 로서는 record 를 사용하기
결론
- 결론 : “1차 스프린트” 에서는 Entity 내부에 검증로직을 두지 않는다.
- JPA 를 사용하면서 추가 래퍼 클래스가 존재하지 않는한 엔티티를 도메인과 같이 사용하고 있게 된다. 도메인 내부에 검증로직을 둔다면, 항상 유효한 값을 가진 도메인 객체가 생성됨을 보장할 수 있다는 장점이 존재한다.
- 하지만 개발의 생산성을 고려했을 때 , 기본적인 작성(검증로직을 엔티티에 포함하지 않도록 작성)을 진행한 이후 , 도메인 내부에 검증로직이 존재하는것이 필요하다고 생각될 경우에는, 검증로직을 추가해 나가는 방식이 좋다고 생각된다.
- 추가적인 의견으로는 DTO 내부에 정책상의 모든 검증로직을 추가하고, 해당 DTO 를 그대로 전달하여 엔티티 인스턴스를 생성하게 된다면 완전한 보장은 불가능하나, 어느정도의 유효한 값을 가질 보장이 되는 것이 아닌가 ? —→ 이에 대한 의견 : DTO 가 여러 엔트리 포인트에서 들어오게 되기 때문에 개발자의 실수로 인해 검증이 제대로 되지 않을 경우, 잘못된 값이 들어올 위험이 존재한다. 또는 현재 Layered architecture 특성상, 계층간 전송이 존재하는데 계층간의 전송을 위한 각각의 DTO 를 정의하는 방식도 존재할 것 같다.
- 추가의견2 DTO에서 검증하고 싶은 값과 엔티티가 검증하고 싶은 값이 다를 수 있는데, DTO는 항상 엔티티에 대한 검증방식을 사전지식처럼 알고 검증을 해야 하기 때문에, 레이어 간 오염이 일어날 수 있다고 생각한다..
(과정)
- 결론 : 엔트리 포인트마다의 DTO 클래스를 sealed interface 클래스로 작성한다 . 그리고 그 엔트리포인트에 대한 Request, Response 를 , 해당 sealed interface 의 허용된 서브클래스로서 작성한다.
- 이 때 이들은 record 클래스로 작성하여(묵시적으로 final ), 해당 파일 내부에 존재하는 서브 클래스 외에는, 해당 sealed 클래스 타입 클래스가 생성될 수 없도록 제한한다.
- 07.28. +추가
- 피드백 1 – 이것은 도메인 코드인가? 검증 코드인가?
