실전 예제 1 - 요구사항 분석과 기본 매핑

요구사항 분석

1. 회원은 상품을 주문할 수 있다.

2. 주문 시 여러 종류의 상품을 선택할 수 있다.

기능 목록

1. 회원 기능 회원 등록 회원 조회

2. 상품 기능 상품 등록 상품 수정

   상품 조회

3. 주문 기능 상품 주문 주문내역 조회

   주문 취소

예상 목업

⭐️ 도메인 모델 분석

1. 회원 - 주문 관계: 회원은 여러 번 주문할 수 있다. (일대다)

2. 주문 - 상품 관계: 주문할때 여러 상품 선택할수있다. 반대로 같은 상품도 여러 번 주문될 수 있다. =>주문 - 상품 : 다대다 관계이기 때문에 중간에 주문상품이라는 모델을 만들어서 일다대, 다대일 관계로 풀어낸다!

테이블 설계

엔티티 설계와 매핑

RDB 중심 설계의 문제점

테이블의 외래키를 객체에 그대로 가져옴 =>객체 그래프 탐색이 불가능 참조가 없으므로 UML도 잘못됨

• Naming 관례 Java : Camel ex) MemberRepository DB : Underscore ex) MEMBER_REPOSITORY 예전에는 대소문자 구분없었기 때문

• 필드에 칼럼 속성으로 length 지정해서 명시해주는 것이 좋다! 개발자가 객체, 필드만 보고도 제약사항을 알고 쿼리를 잘 작성할 수 있다! ex) @Column(length = 10) private String name; @Entity(indexes = @Index(...)) : 사용할 인덱스를 정확하게 지정 가능 JPQL WHERE문 작성 시에 테이블 보면서 왔다갔다 하는 것보다 객체(테이블)보고 하는 것이 훨씬 직관적이기 때문이다.

• JPA, Hibernate 순수하게 사용하면 필드이름이 그대로 사용된다. 실제 개발 시에 스프링 부트를 사용하는데 이 때 Hibernate 네이밍 관례를 오버라이딩해서 바꿀 수 있다. =>보통 DBA 분들이 원하는 것은 orderDate가 아니라 ORDER_DATE (order-date)이다. =>스프링 부트로 JPA, Hibernate 사용하면 스프링 부트 기본설정으로 자바의 Camel 케이스를 대문자(소문자) 언더스코어 형식으로 바꾼다.