Spring/JPA

[JPA] JPA 개발 - 도메인 분석 및 설계

lumana 2024. 9. 29. 02:56

JPA 개발 - 도메인 분석 및 설계

#Spring/DB/JPA

요구사항 분석

먼저 기능 목록을 작성해보자

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

도메인 모델과 테이블 설계

회원 - 주문 - 상품
회원은 여러 상품을 주문할 수 있다. 한 번 주문할 때 상품을 여러 상품을 선택할 수 있고, 하나의 상품이 여러 주문에 포함될 수 있으므로 주문과 상품은 다대다 관계이다.
하지만 이런 다대다 관계는 RDB 뿐만 아니라 엔티티에서도 거의 사용하지 않으므로 주문상품이라는 엔티티를 추가해서 일대다 + 다대일 관계로 풀어야 한다.

상품 분류 : 상품은 도서, 영화, 음반으로 구분되는데 상품이라는 공통 속성을 사용 상속 구조로 표현

주문 - 배송
주문 1건당 배송 1건이므로 일대일 관계

카테고리 - 상품
상품 하나가 여러 카테고리에 속할 수도 있고, 카테고리 하나가 여러 상품을 담을 수도 있으므로 다대다 관계
얘도 다대다 관계라서 테이블 분석할 때 매핑 테이블을 중간에 만들어줄 것이다.

왜 카테고리-상품은 다대다 관계로 도메인을 나타냈나요?

내 생각에는 비즈니스 요구사항 관점에서 차이이다. 주문할 때는 상품당 상품의 수량이 필요하기 때문에 주문 상품이라는 도메인을 두는게 비즈니스 관점에서도 좋지만(주문 수량을 넣을 수도 있고, 주문 가격을 넣을 수도 있음), 카테고리-상품의 경우 비즈니스 로직이 따로 필요하지 않기 때문에 도메인 모델을 만들 때 다대다 관계로 표현한 것 같다.

회원 엔티티 분석

회원(Member): 이름과 임베디드 타입인 주소( Address ), 그리고 주문( orders ) 리스트를 가진다.

주문(Order): 한 번 주문시 여러 상품을 주문할 수 있으므로 주문과 주문상품( OrderItem )은 일대다 관계다. 주문은 상품을 주문한 회원과 배송 정보, 주문 날짜, 주문 상태( status )를 가지고 있다. 주문 상태는 열거형을 사용했는데 주문( ORDER ), 취소( CANCEL )을 표현할 수 있다.

주문상품(OrderItem): 주문한 상품 정보와 주문 금액( orderPrice ), 주문 수량( count ) 정보를 가지고 있다. (보통 OrderLine , LineItem 으로 많이 표현한다.)

상품(Item): 이름, 가격, 재고수량( stockQuantity )을 가지고 있다. 상품을 주문하면 재고수량이 줄어든다. 상품의 종류로는 도서, 음반, 영화가 있는데 각각은 사용하는 속성이 조금씩 다르다.

배송(Delivery): 주문시 하나의 배송 정보를 생성한다. 주문과 배송은 일대일 관계다.

카테고리(Category): 상품과 다대다 관계를 맺는다. parent , child 로 부모, 자식 카테고리를 연결한다.

주소(Address): 값 타입(임베디드 타입)이다. 회원과 배송(Delivery)에서 사용한다.

참고사항
Member와 Order는 양방향 관계. 가급적으로 단방향으로 하는게 좋긴 한데 예제니까 양방향으로 씀.

주의할 점
멤버가 주문 목록을 가진다고 생각할 수 있지만 시스템 상으로는 동급으로 놓고 생각해야 한다. 실무에서는 회원이 주문을 참조하지 않고, 주문이 회원을 참조하는 것으로 충분하다

JPA 로그로 나오는 ddl 스크립트는 참고용이지, 그대로 사용하면 안 된다. 쓸거면 수정해서 사용해야 한다.

MEMBER: 회원 엔티티의 Address 임베디드 타입 정보가 회원 테이블에 그대로 들어갔다. 이것은 DELIVERY 테이블도 마찬가지다.

ITEM: 앨범, 도서, 영화 타입을 통합해서 하나의 테이블로 만들었다. DTYPE 컬럼으로 타입을 구분한다.

참고: 실제 코드에서는 DB에 소문자 + _(언더스코어) 스타일을 사용하겠다. 데이터베이스 테이블명, 컬럼명에 대한 관례는 회사마다 다르다. 보통은 대문자 + _(언더스코어)나 소문자 + _(언 더스코어) 방식 중에 하나를 지정해서 일관성 있게 사용한다. 강의에서 설명할 때는 객체와 차이를 나타내기 위해 데이터베이스 테이블, 컬럼명은 대문자를 사용했지만, 실제 코드에서는 소문자 + _(언더스코어) 스타일을 사용하겠다.

연관관계 매핑 분석

한 문장으로 요약 : FK가 있는 쪽에서 매핑을 한다. 자동차와 바퀴라면 바퀴에서 매핑해야 한다.

참고: 보통 종속적인 쪽이 외래 키를 가진다.

간단한 비유 | 선생님과 학생 30명이 있을 때, 선생님이 학생 30명 각각에게 모르는 게 있는지 일일히 물어보는 것 vs 학생 개개인이 모르는게 있을 때 선생님한테 물어보는 것

현실세계에서는 선생님이 학생을 관리하는 것처럼 보이지만, 학생이 선생님을 관리(?)해야 효율적이다.

회원 - 주문 : 일대다, 다대일의 양방향 관계이므로 연관관계의 주인을 정해야 한다. 외래키를 가져온 곳에서 연관관계 주인을 정하자. (= 외래 키가 있는 주믄을 연관관계의 주인으로 정하자)

주문상품과 주문: 다대일 양방향 관계다. 외래 키가 주문상품에 있으므로 주문상품이 연관관계의 주인이다. 그러므로 OrderItem.order 를 ORDER_ITEM.ORDER_ID 외래 키와 매핑한다.
이것도 회원 - 주문과 유사하다.

주문상품과 상품: 다대일 단방향 관계다. OrderItem.item 을 ORDER_ITEM.ITEM_ID 외래 키와 매핑한다.

주문과 배송: 일대일 양방향 관계다. Order.delivery 를 ORDERS.DELIVERY_ID 외래 키와 매핑한다.

1 : 1 관계에서는 FK를 둘 중 어디에 둬도 된다. 여기선 Order에 뒀기 때문에 Orders에 있는 Delivery가 연관관계의 주인이 된다.

카테고리와 상품: @ManyToMany 를 사용해서 매핑한다.(실무에서 @ManyToMany는 사용하지 말자. 여기서는 다대 다 관계를 예제로 보여주기 위해 추가했을 뿐이다)

참고: 외래 키가 있는 곳을 연관관계의 주인으로 정해라. 연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스상 우위에 있다고 주인으로 정하면 안된 다.. 예를 들어서 자동차와 바퀴가 있으면, 일대다 관계에서 항상 다쪽에 외래 키가 있으므로 외래 키가 있는 바퀴 를 연관관계의 주인으로 정하면 된다. 물론 자동차를 연관관계의 주인으로 정하는 것이 불가능 한 것은 아니지만, 자동차를 연관관계의 주인으로 정하면 자동차가 관리하지 않는 바퀴 테이블의 외래 키 값이 업데이트 되므로 관리와 유지보수가 어렵고, 추가적으로 별도의 업데이트 쿼리가 발생하는 성능 문제도 있다. 자세한 내용은 JPA 기본 편을 참고하자.

참고 : FK를 꼭 걸어야 하나?

실시간 트래픽이 중요하고 정확성보다는 잘 서비스 유연하게 되는 것은 FK 빼고 인덱스만 잡아도 되고, 금전적인 이유 등으로 정확성이 필요하다면 FK를 걸어보는 것에 대해 고민해봐야 한다.

엔티티 클래스 개발

실무에서는 가급적 Getter는 열어두고, Setter는 꼭 필요한 경우에만 사용하는 것을 추천
Setter를 막 열어두면 가까운 미래에 엔티티가 도대체 왜 변경되는지 추적 하기 점점 힘들어진다. 그래서 엔티티를 변경할 때는 Setter 대신에 변경 지점이 명확하도록 변경을 위한 비즈니스 메서드를 별도로 제공해야 한다.

참고) mappedBy

집과 방의 관계로 비유해보겠습니다.

Parent 엔티티는 집, Child 엔티티는 집에 속한 방이라고 가정해봅시다.
각 방(Child)은 하나의 집(Parent)에 속할 수 있습니다. 즉, Child는 Parent를 참조합니다.
반대로, 집(Parent)은 여러 방(Child)을 가질 수 있습니다.

⠀주인 측과 비주인 측

방(Child): 집의 주소(parent_id)를 알고 있으며, 직접 외래 키를 관리합니다. (주인 측)
집(Parent): 방 목록만 알고 있으며, 실제 외래 키는 관리하지 않습니다. (비주인 측)

⠀mappedBy의 역할

Parent 엔티티는 Child 엔티티의 parent 필드를 통해 방들이 어떤 집에 속하는지 알 수 있습니다.
mappedBy = "parent"는 "이 집(Parent)은 방(Child)의 parent 필드를 통해 관계를 관리한다"고 JPA에 알려줍니다.

회원 엔티티


 package jpabook.jpashop.domain;
 import javax.persistence.*;
 import java.util.ArrayList;
 import java.util.List;
 @Entity
 @Getter @Setter
 public class Member {
     @Id @GeneratedValue
     @Column(name = "member_id")
     private Long id;
     private String name;
     @Embedded
     private Address address;
     @OneToMany(mappedBy = "member")
     private List<Order> orders = new ArrayList<>();
 }

@Embedded

내장 타입(= 임베디드 타입, 값 타입)을 포함했다~

회원 - 주문

mappedBy = “member”
- 이 Member 엔티티는 orders의 member필드를 통해서 관계를 관리한다.
- 회원과 주문은 양방향 OneToMany이네? 양방향이니까 연관관계 주인을 정하자! 연관관계 주인은 FK가 있는 쪽이니 orders의 member 필드를 통해서 관계를 맺어준다고 알려주자. (mappedBy)

참고: 엔티티의 식별자는 id 를 사용하고 PK 컬럼명은 member_id 를 사용했다. 엔티티는 타입(여기서는 Member )이 있으므로 id 필드만으로 쉽게 구분할 수 있다. 테이블은 타입이 없으므로 구분이 어렵다. 그리고 테이블은 관례상 테이블명 + id 를 많이 사용한다. 참고로 객체에서 id 대신에 memberId 를 사용해도 된다. 중요한 것은 일관성이다.

주문 엔티티


package jpabook.jpashop.domain;

import jakarta.persistence.*;
import lombok.Getter;
import lombok.Setter;

import java.time.LocalDateTime;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

@Entity
@Table(name = "orders")
@Getter @Setter
public class Order {
    @Id
    @GeneratedValue
    @Column(name = "order_id")
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id")
    // 여기에 값을 세팅하면 FK 값이 다른 멤버로 변경된다
    private Member member;

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL) // order에 의해서 매핑
    private List<OrderItem> orderItems = new ArrayList<>();

    /*
    persist(orderItemA)
    persist(orderItemB)
    persist(orderItemC)
    persist(order)

    에서 Cascade를 사용하면
    persist(order)로, 위 3줄을 지울 수 있다.
    * */

    @OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    @JoinColumn(name = "delivery_id")
    private Delivery delivery;

    private LocalDateTime orderDate;

    @Enumerated(EnumType.STRING)
    private OrderStatus status; // 주문상태 [ORDER, CANCEL]

    //==연관관계 메서드==//
    // 컨트롤 하는 쪽에 연관관계 메서드가 있는게 좋다.
    public void setMember(Member member) {
        this.member = member;
        member.getOrders().add(this);
    }

    public void addOrderItem(OrderItem orderItem) {
        orderItems.add(orderItem);
        orderItem.setOrder(this);
    }

    public void setDelivery(Delivery delivery) {
        this.delivery = delivery;
        delivery.setOrder(this);
    }

   /* public static void main(String[] args) {
        // 원래대로라면 비즈니스 로직에서 아래 처럼 값을 양방향으로 넣어줘야 한다.
        // 이 두개를 묶어주는게 연관관계 메서드이다.
        Member member = new Member();
        Order order = new Order();

        member.getOrders().add(order);
        order.setMember(member);
    }*/
}

주문 - 멤버

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "member_id")
private Member member;

Member랑은 다대일 양방향 관계네? ManyToOne이고, 연관관계 주인이 나네? —> JoinColumn으로 member_id를 통해서 member를 참조해야겠다.

여기에 값을 세팅하면 FK 값이 다른 멤버로 변경된다. 즉 이 엔티티가 member_id와 연관관계에서 주인이다!

XToOne : 지연처리로 설정하자(자세한 내용은 아래에)

주문 - 주문 아이템

@OneToMany(mappedBy = "order", cascade = CascadeType.ALL) // order에 의해서 매핑
private List<OrderItem> orderItems = new ArrayList<>();

주문이랑 주문 아이템은 일대다 양방향 관계네? OneToMany고, 연관관계 주인을 정해줘야 하는데, FK가 orderItem쪽에 있이니 orderItem의 order필드를 통해서 관계를 맺어준다고 알려주자. (mappedBy)

cascade 옵션 : orderItems에 데이터를 넣어두고, order를 저장하면 orderItems도 같이 저장된다. cascade가 없으면 jpa로 orderItems 3개를 저장하고 다음에 order를 jpa에다가 persist해서 저장해야 한다.

persist(orderItemA)
persist(orderItemB)
persist(orderItemC)
persist(order)

에서 Cascade를 사용하면
persist(order)로, 위 3줄을 지울 수 있다.
*/

적용 기준 : 프로젝트의 요구사항에 따라서 결정하자.
order가 삭제되면 필연적으로 orderItem이 모두 사라지므로 cascade를 붙여주는게 편한다. 또 예를 들어보자면, member를 삭제할 때 그 멤버에 대한 order들도 무조건 삭제하기로 했다면 cascade를 사용해주는 게 편하다. order가 사라지지 않는다면 안쓰는게 맞다. 이 강의에서는 후자를 선택한듯

참고) 연관관계 주인 정하기
Member도 주문을 수정할 수 있고, 주문도 Member를 수정할 수 있다. (양방향으로 설계했으니까)
그러면 JPA는 어디에 값이 연관되야 FK를 바꾸지? 뭘 봐야할지 혼동된다.

Member에는 값을 넣어두고 Order에는 값을 안넣었을 수도 있고
반대로 Order에는 값을 넣어두고 Member에는 값을 안넣었을수도 있다.
JPA는 누가 FK 값을 업데이트 해야할 지 혼동이 오게된다.

JPA에서는 FK 업데이트 하는 것은 둘 중 하나만 선택하도록 약속되어있다.
객체는 변경 포인트가 두 군데지만, 테이블은 FK 하나만 변경하면 된다. 이를 JPA도 맞춰둔 것.

단방향에서는 연관관계 주인을 정할 필요가 없다. 참조하는 쪽이 주인이기 때문이다.

주문 - 배송

@OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
@JoinColumn(name = "delivery_id")
private Delivery delivery;

Delivery랑은 일대일 양방향이네? OneToOne이고, 양방향이니 연관관계 주인을 정해줘야 겠지? 근데 비즈니스를 고려하니 Order에서 FK를 관리하는게 좋겠다 주인이 나네? JoinColumn, FK 칼럼은 delivery_id

XToOne : 지연처리로 설정하자(자세한 내용은 아래에)

cascade = CascadeType.ALL : 주문을 하면 배송이 무조건 생기고, 주문 취소(삭제)되면 배송이 무조건 사라짐

주문시간
LocalDateTime : java8부터 hibernate가 LocalDateTime을 알아서 지원해준다.

주문 상태

@Enumerated(EnumType.STRING)
private OrderStatus status; // 주문상태 [ORDER, CANCEL]

@Enumberated : 데이터베이스에 Enum을 저장할 때 Integer로 저장할건지, String으로 저장할건지 알려준다.
- EnumType.ORDINAL은 문자열을 오름차순으로 정수로 할당해서 저장하는데, 새로운 상태가 추가되었을 때 기존 상태 숫자가 바뀌므로 왠만하면 사용하지말자.
- EnumType.STRING은 문자열로 저장한다.

Enum 타입은 @Enumerated를 달아줘야 하고, EnumType으로 ORDINAL(디폴트), STRING을 넣을 수 있다. ORDINAL은 숫자로 들어가서, 중간에 다른 상태가 생기면 문제가 생긴다. READY, XXX, COMP : XXX가 들어오면 COMP가 밀림. 따라서 STRING으로 쓰자

연관관계 메서드
양방향 관계를 가지는 member와 order를 생각해보자.

주문 한 건이 추가된다고 하면 양방향이기 때문에 값을 양방향으로 넣어줘야 한다.
(물론 db 저장할 때는 연관관계 주인에만 값이 있으면 되지만, 로직 처리할 때는 둘 다 값이 있어야 한다.)

 public static void main(String[] args) {
     // 원래대로라면 비즈니스 로직에서 아래 처럼 값을 양방향으로 넣어줘야 한다.
     // 이 두개를 묶어주는게 연관관계 메서드이다.
     Member member = new Member();
     Order order = new Order();

     member.getOrders().add(order);
     order.setMember(member);

그런데 이렇게 양방향으로 값을 넣어주기 위해 두 번 나눠서 처리이 귀찮기도 하고, 실수를 할 확률도 올라간다. 따라서 두 로직을 하나로 묶어주는 메서드를 만들어서 사용한다. 이 메서드를 연관관계 메서드라고 한다.

public void setMember(Member member) {
        this.member = member;
        member.getOrders().add(this);
    }

Order 입장에서는 member 정보를 받아서 이 멤버로 설정해주고, 해당 멤버의 order에다가 자신을 추가해주면 양방향으로 값이 들어가게 된다.

그런데 이 연관관계 메서드는 어느쪽에 두는게 좋을까? Member? Order?
핵심적으로 컨트롤 하는 쪽에 연관관계 메서드가 있는게 좋다. (비즈니스 로직의 관점에서)

Order에서 멤버를 설정해주기 때문에 Order에 연관관계 메서드를 두는게 좋다.
이와 마찬가지로 Order는 OrderItem과 Delivery과 양방향 관계를 맺는데, 비즈니스 관점에서 보면 둘 다 Order에서 컨트롤하므로 Order에서 원자적으로 관리해주는게 좋다.

	public void addOrderItem(OrderItem orderItem) {
        orderItems.add(orderItem);
        orderItem.setOrder(this);
    }

    public void setDelivery(Delivery delivery) {
        this.delivery = delivery;
        delivery.setOrder(this);
    }

Order와 OrderItem의 경우 연관관계 주인이 OrderItem이므로 orderItem을 받으면 orderItem 엔티티에 나의 order정보를 세팅해야하고, 내 엔티티(Order)에 있는 orderItems 리스트에 매개변수로 받은 orderItem을 추가해준다.

Order와 Delivery의 경우 연관관계 주인이 Order이므로 delivery를 받아서 내 delivery에 설정해주고, delivery의 Order필드에는 나의 정보를 설정해준다.

주문상태 ENUM

package jpabook.jpashop.domain;

public enum OrderStatus {
    ORDER, CANCEL
}

주문상품 엔티티

package jpabook.jpashop.domain;

import jakarta.persistence.*;
import jpabook.jpashop.domain.item.Item;
import lombok.Getter;
import lombok.Setter;

@Entity
@Getter
@Setter
public class OrderItem {

    @Id
    @GeneratedValue
    @Column(name = "order_item_id")
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "item_id")
    private Item item;

    @ManyToOne(fetch = FetchType.LAZY) // Order는 여러 개의 OrderItem, OrderItem은 하나의 Order
    @JoinColumn(name = "order_id") // 여기서 값을 설정하면 FK 값이 다른 order로 변경 (연관관계 주인)
    private Order order;

    private int orderPrice; // 주문 가격
    private int count; // 주문 수량
}

OrderItem - Item

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "item_id")
private Item item;

OrderItem과 Item은 다대일 단방향 관계이므로 ManyToOne
OrderItem이 다(FK)이므로 JoinColumn, FK 칼럼은 item_id

OrderItem - Order

@ManyToOne(fetch = FetchType.LAZY) // Order는 여러 개의 OrderItem, OrderItem은 하나의 Order
@JoinColumn(name = "order_id") // 여기서 값을 설정하면 FK 값이 다른 order로 변경 (연관관계 주인)
private Order order;

OrderItem과 Order는 다대일 양방향이므로 ManyToOne
연관관계 주인은 FK가 있는 OrderItem(나)
- 따라서 JoinColumn, FK 칼럼은 order_id

상품 엔티티

package jpabook.jpashop.domain.item;

import jakarta.persistence.*;
import jpabook.jpashop.domain.Category;
import lombok.Getter;
import lombok.Setter;

import java.util.ArrayList;
import java.util.List;

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "dtype")
@Getter @Setter
public abstract class Item {
// 상속관계 전략을 부모 테이블에 지정해야 한다.(싱글 테이블 전략이므로)
    @Id
    @GeneratedValue
    @Column(name = "item_id")
    private Long id;

    private String name;
    private int price;
    private int stockQuantity;

    @ManyToMany(mappedBy = "items")
    private List<Category> categories = new ArrayList<>();

}

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
싱글 테이블 전략을 사용한다. 한 테이블에 다 때려넣고 DTYPE column으로 어떤 자식 데이터가 저장되었는지 구분한다. 싱글 테이블 상속관계 전략은 부모 테이블에 지정해야 한다.

InheritanceType.JOINED : 가장 정교화된 스타일
InheritanceType.SINGLE_TABLE : 한 테이블에 다 때려박기
InheritanceType.TABLE_PER_CLASS : 북, 무비, 앨범 3개의 테이블만 나오는 전략

@DiscriminatorColumn(name = "dtype")
dtype 칼럼으로 구분한다.

Item - Category

@ManyToMany(mappedBy = "items")
private List<Category> categories = new ArrayList<>();

아이템과 카테고리는 다대다 양방향 관계이다.
- ManyToMany
- 중간 테이블이 숨겨져 있기 때문에자기도 모르는 복잡한 조인의 쿼리(Query)가 발생하는 경우가 생길 수 있기 때문에 ManyToMany는 실무에서 사용하지 말자
- 다대다 관계에서는 둘중 아무곳이나 편한곳을 연관관계의 주인으로 잡으면 된다.
  - 여기서는 Category를 연관관계 주인으로 사용했다.
- Category의 items 필드에 의해 관리된다~ (mappedby = “items”)
- 양방향이니까 연관관계 메서드도 만들어주는게 좋은데, Category를 주인으로 정했으니 그냥 연관관계 메서드도 카테고리에 만들자~

상품 - 도서 엔티티

package jpabook.jpashop.domain.item;

import jakarta.persistence.DiscriminatorValue;
import jakarta.persistence.Entity;
import lombok.Getter;
import lombok.Setter;

@Entity
@DiscriminatorValue("B")
@Getter @Setter
public class Book extends Item{
    private String author;
    private String isbn;
}

@DiscriminatorValue("B") : 싱글 테이블이니까 DB 입장에서 저장할 때 구분할 수 있어야 한다. 이 때 넣는 값을 “B”로 한다.

상품 - 영화 엔티티, 음반 엔티티는 생략

배송 엔티티

package jpabook.jpashop.domain;

import jakarta.persistence.*;
import lombok.Getter;
import lombok.Setter;

@Entity
@Getter
@Setter
public class Delivery {

    @Id
    @GeneratedValue
    @Column(name = "delivery_id")
    private Long id;

    @OneToOne(fetch = FetchType.LAZY, mappedBy = "delivery")
    private Order order;

    @Embedded
    private Address address;

    @Enumerated(EnumType.STRING)
    private DeliveryStatus status; // READY, COMP(배송)
}

배송 - 주문

@OneToOne(fetch = FetchType.LAZY, mappedBy = "delivery")
private Order order;

배송과 주문은 일대일 양방향 관계
- OneToOne
- 일대일에 양방향이니까 주인은 맘대로 해도 되는데 아까 Order로 잡음
- 나는 Order 엔티티의 delivery 필드에서 관리된다(mappedby = “delivery”)

XToOne : 지연처리로 설정하자(자세한 내용은 아래에)

참고 : 1대1 관계는 fk를 어디에 둬도 상관 없다. 각자 장단점이 있음.

Access를 많이 하는 곳에 두는걸 선호한다. Delivery 보단 Order를 많이 조회해서 Order에 FK를 두자

이에 따라 Order가 연관관계 주인이 된다.

Address
값 타입(Embedded)를 사용하므로 @Embedded를 달아준다.

배송 상태(DeliveryStatus)
얘도 Enum을 쓰고, EnumType은 String으로 하자. @Enumerated(EnumType.STRING)

package jpabook.jpashop.domain;

public enum DeliveryStatus {
    READY, COMP
}

카테고리 엔티티

package jpabook.jpashop.domain;

import jakarta.persistence.*;
import jpabook.jpashop.domain.item.Item;
import lombok.Getter;
import lombok.Setter;

import java.util.ArrayList;
import java.util.List;

@Entity
@Getter
@Setter
public class Category {

    @Id
    @GeneratedValue
    @Column(name = "category_id")
    private Long id;

    private String name;

    @ManyToMany
    @JoinTable(name = "category_item",
            joinColumns = @JoinColumn(name = "category_id"),
            inverseJoinColumns = @JoinColumn(name = "item_id"))
    private List<Item> items = new ArrayList<>();

    // 셀프로 양방향 연관관계를 건다.
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "parent_id")
    private Category parent;

    // 자식은 카테고리 여러 개를 가질 수 있음
    @OneToMany(mappedBy = "parent")
    private List<Category> child = new ArrayList<>();

    //==연관관계 메서드==//
    public void addChildCategory(Category child) {
        this.child.add(child);
        child.setParent(this);
    }
}

카테고리 - 아이템

@ManyToMany
@JoinTable(name = "category_item",
            joinColumns = @JoinColumn(name = "category_id"),
            inverseJoinColumns = @JoinColumn(name = "item_id"))
private List<Item> items = new ArrayList<>();

카테고리와 아이템은 다대다 양방향 관계이고, 아까 위에서 카테고리를 연관관계 주인으로 잡았다.
- ManyToMany
- 다대다를 위해서는 중간 매핑 테이블이 있어야 하고, 따라서 @JoinTable을 사용한다.
  - 중간 테이블 이름은 category_item
  - category와 category_item은 결국 1대 다 관계가 된다.
    - 여기서 연관관계 주인은 category_item이고, category_item 입장에서 fk 칼럼명은 category_id이다.
  - item과 category_item또한 1대다 관계이다.
    - 여기서 연관관계 주인은 category_item이고, category_item 입장에서 fk 칼럼명은 item_id이다.
    - 근데 나(Category)입장에서 Item은 상대쪽 엔티티이므로, inverseJoinColumns에 @JoinColumn을 넣어줘야 한다.
카테고리와 아이템은 양방향이였고, 주인도 여기인데다가 카테고리별로 엑세스를 하는 로직을 생각해서 여기다가 연관관계 메서드를 만들어도 되는데, 실무에서는 다대다를 쓸 일이 없고, 앞으로 진행할 때도 다대다는 사용하지 않을거임 ->강의에서 따로 안 만든다.

부모, 자식 카테고리

// 셀프로 양방향 연관관계를 건다.
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "parent_id")
    private Category parent;

부모가 누군지를 필드에 담고, 내가 자식이 된다.(트리 구조 생각하면 될 듯)
자식 카테고리와 부모 카테고리는 다대1 양방향 관계이다.
- ManyToOne
- 연관관계 주인은 자식(나) FK 칼럼은 parent_id
XToOne : 지연처리로 설정하자(자세한 내용은 아래에)

    // 자식은 카테고리 여러 개를 가질 수 있음
    @OneToMany(mappedBy = "parent")
    private List<Category> child = new ArrayList<>();

자식들을 필드에 담고, 내가 부모가 된다
부모와 자식은 1대 다 양방향이다.
- OneToMany
- 연관관계 주인은 Child Child 엔티티의 parent 필드에 의해 관리된다.(mappedBy)

//==연관관계 메서드==//
    public void addChildCategory(Category child) {
        this.child.add(child);
        child.setParent(this);
    }

양방향이니까 연관관계 메서드를 넣어줄 수 있다.
- 부모쪽에서 연관관계 메서드를 만든다고 하자.
- child를 받아서 내 child에 추가해주고, child에는 나를 설정해준다.

주소 값 타입

package jpabook.jpashop.domain;

import jakarta.persistence.Embeddable;
import lombok.Getter;
import lombok.Setter;

@Embeddable
@Getter // Setter는 없음. 값 타입은 Immutable하게 , 변경이 되면 안됨. 생성자가 있어야 함 Setter 제공 x
public class Address {

    private String city;
    private String street;
    private String zipcode;

    protected Address() {
    }

    public Address(String city, String street, String zipcode) {
        this.city = city;
        this.street = street;
        this.zipcode = zipcode;
    }
}

값 타입은 Immutable하게 해야 한다. 생성자를 통해서 만들어지고, 값이 바뀌면 안된다. Setter는 없다.

참고: 값 타입은 변경 불가능하게 설계해야 한다. @Setter 를 제거하고, 생성자에서 값을 모두 초기화해서 변경 불가능한 클래스를 만들자. JPA 스펙상 엔티티나 임베디드 타입( @Embeddable )은 자바 기본 생성자(default constructor)를 public 또는 protected 로 설정해야 한다. public 으로 두는 것 보다는 protected 로 설정하는 것이 그나마 더 안전하다. JPA가 이런 제약을 두는 이유는 JPA 구현 라이브러리가 객체를 생성할 때 리플랙션 같은 기술을 사용할 수 있도록 지원해야 하기 때문이다.

엔티티 설계시 주의점

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

Setter가 모두 열려있다. 변경 포인트가 너무 많아서, 유지보수가 어렵다. 나중에 리펙토링으로 Setter 제거
Setter가 필요하면 비즈니스 메서드를 만들어서 쓰자.

모든 연관관계는 지연로딩으로 설정!

즉시로딩 : Order를 조회할 때 다른 것(member, OrderItem...) 까지 다 로딩. 하나 잘못 건들면 연관된 데이터를 다 가져옴.

기본적으로 전부 LAZY로 세팅하고 패치 조인과 엔티티 그래프를 통해서 원하는 그룹을 실시간으로 가져오자.

즉시로딩( EAGER )은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다.
- Order에서 EAGER로 Member를 설정하면 오더를 조회할 때 Member를 종인해서 같이 가져온다.
- JPQL을 통해 select o From order o; 로 사용하면 select * from order 로 번역이 된다.
- 이 상태에서 쿼리 1개로 Order 100개를 조회하면 EAGER라서 Member에 한방 쿼리가 100개가 날라간다
- 이런걸 N + 1 문제라고 함.
실무에서 모든 연관관계는 지연로딩( LAZY )으로 설정해야 한다.
연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용한다.
@XToOne(OneToOne, ManyToOne) 관계는 기본이 즉시로딩이므로 직접 지연로딩으로 설정해야 한다.
- 주의! OneToMany랑 OnetoOne 기본 패치 전략이 다름!
- XToMany는 기본이 LAZY임
- ManyToOne은 모두 찾아서 LAZY로 바꿔줘야 함

컬렉션은 필드에서 초기화 하자.

컬렉션은 필드에서 바로 초기화 하는 것이 안전하다.

null 문제에서 안전하다.
하이버네이트는 엔티티를 영속화 할 때, 컬랙션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한다. 만약 getOrders() 처럼 임의의 메서드에서 컬랙션을 잘못 생성하면 하이버네이트 내부 메커니즘에 문제가 발생 할 수 있다. 따라서 필드레벨에서 생성하는 것이 가장 안전하고, 코드도 간결하다.

실수할 수 있는 시나리오
set~메서드로 영속화를 해서하이버네이트가 추적할 수 있는 내장 컬렉션으로 바뀜.
바꿨는데 또 set~~해서 컬렉션을 바꿔버리면 하이버네이트 매커니즘이 안돌아감

결론: 필드에서 만들어서 있는 걸 그대로 사용하자

테이블, 컬럼명 생성 전략

스프링 부트에서 하이버네이트 기본 매핑 전략을 변경해서 실제 테이블 필드명은 다름

하이버네이트 기존 구현: 엔티티의 필드명을 그대로 테이블의 컬럼명으로 사용 (SpringPhysicalNamingStrategy )

스프링 부트 신규 설정 (엔티티(필드) 테이블(컬럼))

카멜 케이스 언더스코어(memberPoint member_point)
.(점) _(언더스코어)
대문자 소문자

ex) orderDate order_date

전략을 바꾸고 싶으면 네이밍 전략을 클래스로 구현해서 바꿔치기 하면 된다.(전사 로직)

적용 2 단계 1. 논리명 생성: 명시적으로 컬럼, 테이블명을 직접 적지 않으면 ImplicitNamingStrategy 사용
spring.jpa.hibernate.naming.implicit-strategy : 테이블이나, 컬럼명을 명시하지 않을 때 논리명 적용
 2. 물리명 적용:
spring.jpa.hibernate.naming.physical-strategy : 모든 논리명에 적용됨, 실제 테이블에 적용 (username usernm 등으로 회사 룰로 바꿀 수 있음)

스프링 부트 기본 설정
spring.jpa.hibernate.naming.implicit-strategy:<br> org.springframework.boot.orm.jpa.hibernate.SpringImplicitNamingStrategy spring.jpa.hibernate.naming.physical-strategy:<br> org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy

'Spring > JPA' 카테고리의 다른 글

[JPA] Cascade 적용 기준 (0)	2024.09.29
[JPA] 다대일(N:1) 단방향 VS 양방향 정리 (0)	2024.09.29

현재글[JPA] JPA 개발 - 도메인 분석 및 설계

Brute force Study

배움을 나누는 공간 https://github.com/DawnGlow

Today :
Yesterday :

일	월	화	수	목	금	토
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Brute force Study

[JPA] JPA 개발 - 도메인 분석 및 설계

JPA 개발 - 도메인 분석 및 설계

요구사항 분석

도메인 모델과 테이블 설계

왜 카테고리-상품은 다대다 관계로 도메인을 나타냈나요?

회원 엔티티 분석

연관관계 매핑 분석

엔티티 클래스 개발

참고) mappedBy

회원 엔티티

주문 엔티티

주문상태 ENUM

주문상품 엔티티

상품 엔티티

상품 - 도서 엔티티

배송 엔티티

카테고리 엔티티

주소 값 타입

엔티티 설계시 주의점

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

모든 연관관계는 지연로딩으로 설정!

컬렉션은 필드에서 초기화 하자.

테이블, 컬럼명 생성 전략

'Spring > JPA' 카테고리의 다른 글

'Spring/JPA'의 다른글

티스토리툴바

[JPA] JPA 개발 - 도메인 분석 및 설계

JPA 개발 - 도메인 분석 및 설계

요구사항 분석

도메인 모델과 테이블 설계

왜 카테고리-상품은 다대다 관계로 도메인을 나타냈나요?

회원 엔티티 분석

연관관계 매핑 분석

엔티티 클래스 개발

참고) mappedBy

회원 엔티티

주문 엔티티

주문상태 ENUM

주문상품 엔티티

상품 엔티티

상품 - 도서 엔티티

배송 엔티티

카테고리 엔티티

주소 값 타입

엔티티 설계시 주의점

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

모든 연관관계는 지연로딩으로 설정!

컬렉션은 필드에서 초기화 하자.

테이블, 컬럼명 생성 전략

'Spring > JPA' 카테고리의 다른 글

'Spring/JPA'의 다른글

관련글

티스토리툴바