JPA - 엔티티 맵핑 - 요구사항 분석과 맵핑

- 참조: 자바 ORM 표준 JPA 프로그래밍

- 실전 예제

책에서는 쇼핑몰을 만든다고 가정하고 몇 가지 요구사항을 통해 엔티티 맵핑을 적용해보는 과정이 있다. 내용을 다 기술할수는 없고 몇 가지 생각해볼 내용들이 있다.

• 회원은 상품을 주문할 수 있다.
• 주문시 여러 종류의 상품을 선택할 수 있다.

---

- 도메인 모델 분석

JPA 는 도메인 모델을 다루는데에 있어서 Mybatis 보다 상당한 강점이 있다고 생각한다. Spring Data JPA 문서에서도 domain 이라는 단어자체가 상당히 많이 등장하며, Specifications 부분은 직접적으로 에릭 에반스의 DDD 에서 개념을 가져왔다고 말하고 있다. 

 

위에서 언급한 요구사항 2 가지를 적용해보자.

위 그림은 회원, 주문, 제품간의 관계를 나타낸것이다. 만약 다중성이 헷갈린다면 모든 상황에 쓸 수는 없지만 어떤 요소를 1개라고 고정시켜놓고 반대편 요소가 몇 개일까라고 생각해보면 수월하다. 

 

예를 들어 Member 와 Order 의 경우 회원 1명이라면 주문은 여러 건 할 수 있다. 반면 주문이 1건 이라면 해당 주문에 엮인 회원은 1 명이므로 1 : N 관계이다.(여기서 주문 1건에 엮인 회원이 1명이라는 건 현재 이 어플리케이션의 조건이 그렇다고 가정하고 있다는 뜻이지 모든 어플리케이션의 회원 - 주문간 도메인 제약조건이 꼭 그래야한다는것이 아님을 주의하길 바란다.) 또 주문이 1건이라면 1건의 주문에는 여러 개의 제품이 있을 수 있으며, 제품 1개는 여러 개의 주문에 엮일 수 있기 때문에 M : N 이된다.

 

위의 그림은 요구사항 2 개에 대해 다중성을 직관적으로 그대로 적용시킨 다이어그램이다. 1 : N 은 많이 나올 수 있는 개념이지만 M : N 다중성은 가능하면 피해야 한다. 이럴 경우 비즈니스 제약사항을 넣어서 풀면 매우 좋지만 그렇게 못하면 아래처럼 관계 객체를 넣어서 1 : M, N : 1 로라도 풀어야 한다.

 

---

- 테이블 설계와 엔티티 설계

아래 그림은 다른 항목을 모두 생략하고, 핵심이 되는 Key 값의 관계만을 나타낸것이다. 아래와 같이 DB 를 설계하면 Join 시 누락되는 요소가 없으므로 SQL 작성시 해당 주문에 엮인 회원을 찾는다던지, 해당 주문에 엮인 제품들을 모두 조회할 수 있다.

그렇다면 이 사상을 그대로 가지고 UML 을 아래처럼 설계하면 될까? 데이터의 관점이라면 전혀 문제가 없지만 객체지향 관점에서 UML 을 그려본 사람이라면 당연히 이상하다고 생각할 수 있다. 

예를 들어 "특정 회원의 주문건들을 알고 싶다." 라는 요구사항에 대해 SQL 을 작성할 때 Order 테이블에서 memberId 로 Member의 id 를 Join 조회하면 되니까 상관이 없다.

 

문제는 우리가 위의 요구사항을 Java Code 로 구현할 때 위와 같이 생각하지 않는다는것이다. 특정 회원 id 로 Member 엔티티를 찾고, member.getOrders() 로 주문을 찾으려고할 것이다. 즉 회원의 주문건들을 "참조" 하려고 한다. 그런데 위와 같이 UML 을 설계하면 그렇게 할 수 없다. 책에서는 아직 연관관계 맵핑을 배우지 않고 해당 실전예제를 설명하느라 일부러 위와 같이 UML 을 그린것 같다.

 

연관관계 맵핑까지 생각해서 UML 을 설계한다면 아래와 같이 될 것이라고 생각한다. 아래 내용은 말 그대로 나의 생각이므로 맞거나 좋다고 생각해서 학습용으로 보지말고 비판적인 시각으로 생각해볼거리 정도로만 생각하여 참조하길 바란다.

위에서 [] 안에 각 속성에 대한 다중성을 표시하였다. OrderProduct 와 Product 는 화살표(DirectedAssociation) 으로 표시하였는데, 이는 OrderProduct 가 Product 를 "일반적으로 참조" 하고 있기 때문이다. 직접 연관까지 설명하는건 너무 UML 관련내용을 상세하게 설명하는거라 인터넷을 검색하여 참조하길 바란다.