작성한 질문수 4

2

좋은 질문을 해주셨네요.

예외에 웹 응답 코드 정보를 애노테이션으로 넣는 것도 리포지토리에 JPA 애노테이션을 넣어도 된다면 허용할 수도 있지 않냐는 말씀이군요.

그럼에도 저는 사용을 안 하는 것으로 결정을 했고요. 사실 넣는다고 도메인 쪽에서 예외를 사용할 때 기능에 문제가 생길리는 없겠죠. 그럼에도 제가 이걸 피하려고 했던 이유는 도메인 로직에서 정의된 예외와 웹 응답 코드는 너무 간격이 크다고 느껴졌기 때문입니다.

@Entity는 JPA가 아니라 JDBC를 쓴다고 해도, 이건 도메인 모델 방식에서 이야기 하는, 혹은 DDD에서 말하는 엔티티라는 정보를 주는 것으로도 가치가 있습니다. import까지 찾아가서 이거 JPA 거자나라고 따지고 들지 않는다면, 코드를 읽는데 전혀 방해가 되지 않습니다.

@Query도 마찬가지입니다. 다음에 네이티브 쿼리가 나올 때는 또 고민이 되겠지만, JPA의 @Query에 들어가는 JPQL은 그 표현식 자체가 도메인 언어로 된 엔티티로 쓰여져있습니다. 이게 DB가 아니라 순수한 오브젝트 저장소에서 조회를 한다고 해도 전혀 어색하지 않은 도메인 속성과 잘 맞는 쿼리죠. 애초에 SQL도 비개발자들이 손쉽게 데이터를 조회할 수 있게 만들어진 것인데, JPQL은 도메인 언어만 잘 이해하고 있는 비개발자인 도메인 전문가도 간단한 문법만 배우면, 도메인 지식만 가지고도 얼마든지 조회를 해볼 수 있을 정도로 친숙합니다. 근데 왜 그게 하필 JPA 것을 쓰느냐, 이런 질문에 대해서 그 정도는 충분히 용납될 수 있다고 본 거죠.

반면 도메인 로직을 담은 예외가 웹의 응답 코드로 매칭이 된다. 이건 너무 뜬금없다고 느껴집니다. 헥사곤의 클라이언트가 웹만 있는게 아니니까요. 그런 관점에서 저는 웹이라는 특정 기술에 더 가까이간 응답 코드 정보를 예외에 넣고 싶지는 않았네요.

그런데, 이게 맞고 틀리고의 문제는 아닙니다. 뭐, 어짜피 코드 동작에 영향을 주지 않는 애노테이션이고, 클라이언트는 100%는 아니더라도 주로 웹 응답이 많이 쓰일테니, 넣는 것도 나쁘지 않겠다. 도메인 코드를 읽으면서 웹 응답은 뭘까도 떠올리는 게 개발자에겐 부담은 아니다라고 생각하면 써도 상관없습니다.

하지만 저는 그렇게까지는 쓰고 싶지 않네요.