DB 테이블과 JPA 엔티티를 어떤식으로 매핑할 것인가?

[verus-j]

식별자(id)를 이용해 매핑

• 객체 그리프를 그릴 수 없어, 조회를 join문을 사용해야됨
  ㄴ> 쉽게는 sql문에서 join 쿼리를 만들거나, jpql에서 join 쿼리를 할 수도 있음(이부분은 좀 더 찾아봐야됨)
  ㄴ> 따라서, 조회를 위해서 다른 클래스(Dao나 다른 DB와 상호작용하는 클래스를 만들어야됨)를 사용함
• JPA 엔티티는 명령에 관한 책임만 가지고, 조회를 위한 다른 클래스를 따로 구분하기 때문에 책임이 분리됨
  ㄴ> 명령과 조회는 서로 관심사가 다르고 변경이 다르게 날 수 있기 때문에 분리하는게 좋을 수도 있음
• Study와 Tag의 경우 명령을 수행할 때 각자의 객체가 필요한게 아니고 식별자로 충분함
  ㄴ> 이 부분은 모든 케이스에 적용된다 할 수 없지만, 현재는 충분히 그런 상황임
  ㄴ> 추후 필요하다면 그 때, 객체 매핑으로 변경해도 됨
• Study와 StudyTag를 같은 생명주기로 묶을 수 있음
  ㄴ> Study 자체가 StudyTag의 주인이 될 수 있어 자연스럽게 StudyService나 StudyRepository로 StudyTag를 추가할 수 있음

객체를 이용해 매핑(@ManyToOne, @OneToMany등 을 이용)

• 객체 그래프를 그릴 수 있어, 조회를 JPA를 사용할 수 있음
• 객체를 Repository에서 조회하는 경우가 크게 1. 응답을 위한 조회, 2. 명령을 수행하기 위한 조회로 나눌 수 있음.
  이럴 때 JPA를 사용하면, join fetch 쿼리를 상황에 따라 사용해야할 수 있음
  ㄴ> 즉, JPA 엔티티에 명령과 조회 2가지 책임을 가지게 되고 한쪽의 변경으로 인해 고통 받을 가능성이 큼...
• Study에 Tag를 추가하기 위해서 StudyTag라는 엔티티를 저장해야됨
  • 패키지를 어떻게 관리할까?가 문제임(study, studytag, tag 이런 식으로 만들어지지 않을까 싶음)
  • Study에 Tag를 추가하기 위해서 StudyService가 아닌 StudyTagService를 쓰는게 맞을까?(또는, StudyRepository 외에 StudyTagRepository를 사용하는게 맞을까?)

참고자료

• 우형 기술 블로그 관련 자료
• 범균님 CQRS 아는척 하기
• JPA 프로그래밍 입문
• DDD start
• 도메인 주도 개발 시작하기

[tco0427]