#2 프로젝트 기획 & 도메인 설계

해당 글은 김영한님의 실전 스트링 부트 1를 공부하고 정리한 내용입니다.

 

#프로젝트를 기획해보자

평범한 쇼핑몰, HELLO SHOP을 만들 예정이다. 여기에는 회원이 상품을 주문할 수 있고 판매자가 상품을 등록할 수 있다.  여기에 필요한 기능을 하나하나 목록으로 정리해보자.

프로토타입

1. 도메인	회원(Member) 상품(Item) 주문(Order)
2. 회원기능	회원 등록 회원 조회
3. 상품기능	상품 등록 상품 수정 상품 조회
4. 주문기능	상품 주문 주문 내역 조회 주문 취소
5. 요구사항	상품은 재고 관리가 필요하다. 상품의 종류는 도서, 음반, 영화가 있다. 상품을 카테고리로 구분할 수 있다. 상품 주문시 배송 정보를 입력할 수 있다.

* 요구사항을 상세하게 적을 수록 설계 단계에서 유연하게 만들기 쉬워진다.

---

# 프로토타입을 만들어보자

Kakao Oven이나 기타 프로토타입 툴을 이용하여 원하는 화면을 그려보자.

탈퇴 & 중복회원은 어떻게 처리할 것인가?

상품등록과 수정

주문은 확정 전 취소가능

---

# 도메인과 테이블을 설계해보자.

해당 부분은 데이터베이스 설계를 배우면 자세하게 알게된다. 완벽하게 이해하지 못했더라도 일단 따라하면서 배워보자.

 

@ 도메인의 관계와 제약조건

DB 테이블을 만들기 위해 관계와 제약조건을 파악해보자.

• 회원은 여러 상품을 주문 할 수 있다. 한번 주문할 때 여러 상품을 선택할 수 있다. [회원<->주문<->상품]이 N:N 관계이므로, 중간에 '주문 상품'이라는 엔티티를 추가하여 1:N 관계로 바꿔주자.
• 상품은 도서, 음반, 영화등 여러가지 종류가 있지만, 공통 속성을 사용하므로 상속 구조로 표현했다.

---

@ 도메인 설계

• 회원(Member): 고유값(id), 이름(name), 주소(Address), 주문 리스트(orders)를 가진다.
• 주소(Address): 값타입(=임베디드 타입)이다. 도시(city), 도로명(street), 우편번호(zipcode)를 가진다.
• 배송(Delivery): 고유값(id), 해당 주문(Order), 주소(Address), 배송상태(DeliveryStatus)를 가진다.
• 카테고리(Category): 고유값(id), 카테고리명(name), 해당 상품리스트(items), 부모 카테고리(Parent), 자식 카테고리 리스트(child)를 가진다.
  
  
• 상품(Item): 고유값(id), 상품명(name), 가격(Price), 재고수량(StockQuantity), 카테고리(List)를 가진다.
• 주문상품(OrderItem): 고유값(id), 상품(item), 주문(Order), 주문금액(orderPrice), 주문수량(count)을 가진다.
• 주문(Order): 고유값(id), 주문 회원(Member), 주문상품 리스트(OrderItems), 배송정보(Delivery), 주문날짜(OrderData), 주문상태(OrderStatus)를 가진다.

이렇게 정의를 완료했다면, 객체(엔티티)간의 관계를 테이블로 표현해보자.

참고로 Order는 DB의 [Order by]랑 겹쳐서 Orders라고 적는 경우가 많다.

 

---

@ [객체 관계 -> DB 테이블] 연관관계 매핑

위에서 정의한 도메인들로 테이블 관계를 대략적으로 그려보고, 관계마다 특징과 문제점이 있는지 분석해보자

참고로 DB에 Order by라는 예약어가 있어, Order에 s를 붙인다.

* 해당 예제는 난이도를 낮추기위해 최대한 간단하게 테이블을 작성하였다. 만약 실제 서비스를 생각한다면 더 깊게 살펴보아야한다. 한가지만 예를 들어본다면 주문<->회원간의 관계에서 단순하게 생각하면 '회원이 주문을 하니까, orders를 가지면 되겠구나!' 라고 착각할 수 있다. 그러나 실제 서비스는 회원과 주문은 동급이다.

그 이유는 회원을 통해서 주문이 일어나는 것이 아니라 주문을 생성할 때 회원이 필요하기 때문이다. 이는 개념적으로도, 쿼리문의 동작방식도 이러하다. 즉 사실상 회원과 주문의 1:N 관계는 필요가 없다. 그 외에도 여러 문제가 있지만 지금은 스프링 사용방법을 배우는 것이지, 데이터베이스 수업이 아니므로 일단 넘어가도록 하자.

• 회원(Member) <-> 주문(Orders)
  1:N, N:1의 양방향 관계이다. 따라서 연관관계의 주인을 정해야 하는데, 외래키가 있는 주문을 주인으로 정하는게 좋다. 그러므로 Order.member를 ORDERS.MEMBER_ID 외래키와 매핑한다.
• 주문(Orders) <-> 주문상품(Order_Item)
  주문상품과 주문은 1:N 양방향 관계이다. 외래 키가 주문상품에 있으므로 주문상품이 연관관계의 주인이다. 즉 OrderItem.order를 ORDER_ITEM.ORDER_ID와 매핑한다.
  
  
• 주문상품(Order_Item)과 상품(Item)
  다대일 단방향 관계이다. OrderItem.item 을 ORDER_ITEM.ITEM_ID 외래 키와 매핑한다.
• 주문(Orders)과 배송(Delivery)
  일대일 양방향 관계이다. Oder.delivery 를 ORDERS.DELIVERY_ID 외래키와 매핑한다.
  
  
• 카테고리(Category)와 상품(Item)
  카테고리와 상품도 N:N 관계므로, 그림처럼 엔티티를 추가로 생성해 1:N관계로 풀어야한다.
  하지만 N:N 관계를 사용했을 때 어떠한 문제점이 생기는지 보여줄려고 일부러 @ManyToMany를 사용해 매핑해보도록 하겠다. 이 예제를 통해 왜 실무에서 N:N 관계를 1:N 으로 쪼개야하는지 배워보자.

왜 외래 키가 있는 곳을 연관관계의 주인으로 정하나요?

연관관계의 주인은 단순히 '외래 키를 누가 관리하는가?' 문제이지 비즈니스상 상위 개념이라고 주인으로 정하면 안된다.

예를 들어 자동차와 바퀴가 있다면 1:N 관계에서 항상 N쪽에 외래 키가 있으므로, 외래 키가 있는 바퀴를 연관관계의 주인으로 정하면 된다. 물론 자동차를 주인으로 정하는 방법도 있지만 그렇게 한다면 자동차가 관리하지 않는 바퀴 테이블의 외래 키값이 업데이트 되므로 관리와 유지보수가 어렵다. 또한 추가적으로 별도의 업데이트 쿼리가 필요하여 성능문제도 생기게 된다.

이는 Database와 JPA를 학습하게되면 자세하게 다루니, 이해하지 못했다 하더라도 넘어가도록 하자.

 

---

# 엔티티 클래스 개발

이제 데이터베이스 테이블의 설계를 마쳤다. 테이블을 바탕으로 클래스를 만들어 보자. 스프링에서는 @Entity 어노테이션을 통해 해당 객체가 엔티티임을 알린다. 이를 바탕으로 쿼리문을 자동 생성한다.

 

- 생략 - (추후에 깃허브 업로드 예정)

 

---

# 엔티티 설계시 주의점

@ManyToMany는 사용할 일이 없다.

왜 그런지는 데이터베이스 공부를 하게되면 지겹도록 들을 수 있다. 확장성과 성능 둘다 망해버리니 절대로 쓰지말자.

---

@ RDB에 연결할 ID는 이름을 명확하게 해주자.

객체를 사용할 때는 상관없지만 DB에서 사용할 때에는 이름이 헷갈려 조인할 때 귀찮아진다. 가능하면 [tableName_id] 이런식으로 명확하게 만들어주자.

public class Member {

    @Id
    @GeneratedValue
    @Column(name = "member_id") // id 대신 member_id 사용
    private Long id;
}

---

@ 엔티티에는 가급적 Setter를 사용하지말자.

비즈니스 로직이 아닌 Setter로 변경하게되면 변경 포인트가 너무 많아 유지보수가 어렵다. 나중에 리펙토링으로 Setter를 제거해주도록 하자. 물론 Getter는 단순 조회이기에 그렇게까지 신경 쓸 필요는 없다.

 

가급적 생성자에서 값을 모두 초기화해서 변경 불가능한 클래스를 만들자. 필요하다면 Setter가 아닌 비즈니스 로직에서 처리하도록 만들어야 한다.

---

@ 모든 연관관계는 지연로딩으로 설정하자.

• 즉시로딩( EAGER )은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 그나마 JPA 메서드에서는 자체적으로 최적화를 제공해주지만 JPQL을 실행할 때는 N+1 문제가 자주 발생한다. 
• N+1 문제란, 연관관계가 있는 엔티티를 조회할 때 조회된 데이터 수(N)만큼 쿼리를 추가로 날리는 문제이다.
• 그래서 실무에서 모든 연관관계는 지연로딩( LAZY )으로 설정해야 한다.
• 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용한다.
• 하나만 가져오는 @XToOne(OneToOne, ManyToOne) 관계는 기본이 즉시로딩이므로 직접 지연로딩으로 설정해야 한다.

  

  javax.persistence.FetchType.LAZY

---

@ 컬렉션은 필드에서 초기화하고 손대지말자

생성자 X 수정자 X 필드 O, 메모리 아까워하지 말자.

null 문제에서 안전하게 만들자. 하이버네이트(JPA)는 엔티티를 영속화 할 때 컬렉션을 감싸 하이버네이트의 내장 컬렉션으로 변환한다. 그래서 임의의 메서드에서 컬렉션을 잘못 생성하게되면 영속화 내부 메커니즘에 문제가 생길 수 있다.

Member member = new Member();
System.out.println(member.getOrders().getClass()); // class java.util.ArrayList
em.persist(team); // 영속화. ArrayList -> 감싸버림.
System.out.println(member.getOrders().getClass()); // class 하이버네이트 내장 컬렉션

//출력 결과
class java.util.ArrayList
class org.hibernate.collection.internal.PersistentBag

---

@ 테이블, 칼럼명 생성 규칙

스프링부트를 사용하면 하이버네이트 기본 매핑전략이 변경된다. 즉 실제 테이블 필드명이 다르다. ( 하이버네이트만 사용하면 엔티티의 필드명을 그대로 테이블의 칼럼명으로 사용한다.)

자바에서 사용하는 변수 규칙을 DB에서 자주 사용하는 규칙으로 바꿔준다.

만약 회사에서 다르게 사용하고 싶다면 spring.jpa.hibernate.naming.physical-strategy 클래스를 보고 만들면 된다.

// 스프링부트 설정

// 테이블 이름이 적혀있지 않았을 때 규칙
spring.jpa.hibernate.naming.implicit-strategy:// 이렇게 클래스를 바꿀 수 있다.
org.springframework.boot.orm.jpa.hibernate.SpringImplicitNamingStrategy

// 모든 이름에 적용되는 규칙 규칙
spring.jpa.hibernate.naming.physical-strategy:
org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy

---