DB 테이블과 JPA 엔티티 매핑 방식에 대한 고민

[jaejae-yoo]

@tco0427 @jaejae-yoo

디우 & 그린론: DB 테이블과 JPA 엔티티을 풀어내기 위해 값 객체를 사용하는 방식으로 구현하면서 들었던 고민을 공유합니다.

---

ElementCollection & Embeddable 방법에 동의한 이유?

→ 1) 객체와 데이터베이스 패러다임의 불일치를 해결하는 더 좋은 방법이라고 생각했다.
다대다 연관관계에서 1-N, M-1 으로 풀면 중간에 연관관계 테이블이 생긴다.
그렇게 되면 객체에서 테이블 구조를 그대로 반영해야함.
예를 들어 Study, Member 사이에서는 StudyMember 라고 하는 클래스가 엔티티로 등록되어야한다.
하지만, Embedded, CollectionTable 방법을 사용하면 객체지향적으로 Study와 Member 클래스만 가지고, List<Participant> 라고 하는 필드를 Study가 가지면 되므로 자연스러움.

→ 2) study - tag의 N : M 관계를 studyId라는 값 객체를 통해 엔티티 간의 강한 결합 관계를 끊어낼 수 있을 것이라 생각했지만, 해당 방법이 올바른 방법인지 의문이 든다.

의문점

→ 1) memberId를 가지는 객체가 생기는 것은 자연스러울까?

• id 또한 DB에 종속적인 것이 아닐까?

→ 2) memberId로 연결하는 것이 객체지향적일까?

• memberId 로 연결하는 것은 객체지향적이지 않다는 느낌이 든다. (지하철 미션에서도..)
• memberId가 아니라 Member 객체와 연관지으면 어색한 방법일까?

→ 3) memberId로 관계를 끊어낼 수 있다고 했는데, 왜 그래야 하는지?

→ 4) study 안에서 member를 관리하는 게 적절할까?

• member가 종속적인 느낌이 든다.

→ 5) membeId 말고 Member를 가지고 getter에서 id 꺼내서 사용해도 되지 않을까? (쿼리날릴 때)

→ 6) 명령과 조회를 왜 분리해야 하는가?

• 지금 현재 각 도메인 별로 패키지 구조를 나누고 있고, 각 도메인별로 CRUD가 함께 있으면 문제가 있을까?
• R과 CUD를 분리했을 때 얻는 이점이 뭘까?

[tco0427]

[tco0427]

memberId를 DB와는 무관한, 각 객체의 참조값처럼 하나의 식별자로써 역할을 한다고 이해해볼 수 있다. 그렇게 생각하면 DB에 종속적인 것 만이라고 이야기하기는 어렵다.

명령과 조회를 분리하는 것에는 현재의 방식으로 진행을 했을 때 CRUD가 하나의 클래스안에 있으면 책임이 너무 커질 수 있다. 따라서 이를 분리한다고 이해해도 좋을 것 같다.

memberId가 아닌 member를 가지게 되면 member를 조회할 때 member와 관련된 모든 엔티티를 함께 조회해주어야한다. 하지만 memberId의 경우 Study 테이블에 FK로써 존재하므로 id만을 가지면 Study 테이블 조회만으로 충분해진다.