서론 개인 프로젝트를 진행하던 중 예외 코드가 하드 코딩으로 관리되고 있어서 방법을 찾아보던 중 세 가지 후보를 고민했다. 설정 파일 DB enum 비지니스 커스텀 예외는 Enum 실무에서는 설정 파일과 DB를 사용했었다. 이미 그렇게 되어있어 고민없이 사용하게 되었다. 이 때 느낀 것은 아래와 같았다. 비지니스 커스텀 예외란 직접 개발자가 throw new 하는 것으로 정의했다. 설정 파일 코드를 직접 문자열로 매핑을 해야한다. 생산성 저하 객체에 매핑하여 사용할 수 있지만 설정 파일을 읽어오기 위한 빈 주입이 필요하기 때문에 번거로울 수 있다. DB 네트워킹이 필요하다. 하지만 처음 메인화면 오픈 시 캐싱해두면 되기 때문에 문제는 아니다. 재적용이 아주 쉽다. 배포가 필요가 없다. 최고의 장점이다. ..

서론 여기까지 고민하게 된 계기는 Entity에서 필드 검증을 직접해야 할까? 였다. 그러면 항상 로직을 짜아하고, null체크와 같은 것들은 굉장히 중복되는 것들인데 모든 Entity에 비슷한 코드가 들어가게 된다. 그리고 Entity 검증 테스트를 작성할 필요가 있을까? 단순한 검증 로직 귀찮은데? 기존에는 아래 코드와 같이 직접 StringUtils.isBlank와 같이 검증을 했다. 그리고 테스트 작성도 했다. @Entity public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String email; @Column(nullable = false) private Str..