02. 도메인 분석 설계

쇼핑몰 예제에 대한 테이블을 설계함

도메인 모델과 테이블 설계#

  • ITEM 테이블은 상속관계를 싱글 테이블 전략으로 사용함
  • FK를 가지고 있는 엔티티가 연관관계의 주인이 되야함
    • 비즈니스의 우위에 있다고 연관관계의 주인으로 정하면 안됨

피해야할 것#

공부를 위해 아래를 넣었으나, 실제에선 피해야 함

  • 다대다 관계는 피하자 (실무에선 @ManyToMany 지양)
    • 중간에 매핑 테이블이 생김
  • 양방향 매핑은 지양
    • 양방향 관계를 한다면, 관계 주인을 명시해야함 (일대다이면 다인쪽에 주인으로)
    • 주인이 아닌쪽은 조회용으로만 쓰기

엔티티 클래스 개발#

주의사항#

  • Getter, Setter 범위는 항상 고려하자
    • 그냥 열어버리면 언제 어디서 변경이 발생한지 찾기 어려움
    • 변경용 별도의 비즈니스 로직을 만드는게 좋음
  • 실무에서는 ManyToMany 지양
    • 중간 테이블 수정에 어려움 + 운영에 어려움
  • DDL 스크립트는 따로 사용
    • 추출한 것 가지고 수정하여 DDL 스크립트 적용

연관관계 주인#

  • FK 필드 교체를 책임지는 클래스를 연관관계 주인이라 함
  • FK 를 가지고 있는 테이블의 클래스를 연관관계 주인으로 설정하자

값 타입#

  • 생성 할때만 세팅하고, Setter는 제공 X
  • Entity JPA 스펙 상 기본생성자를 protected or public으로 제공해야함
    • 리플렉션, 프록시 기능을 쓰기위해

엔티티 설계 시 주의점#

  • 가급적 Setter 를 사용하지 말자
  • 모든 연관관계는 지연관계(LAZY)를 기본적으로 설정 권장
    • 연관된 엔티티는 fetch join or 엔티티 그래프 기능을 이용
    • OneToOne ManyToOne 기본이 EAGER 즉시 로딩이라 LAZY로 설정 권장
  • 컬렉션은 필드에서 초기화 하자
    • null 문제에서 안전
    • 엔티티 컬렉션은 바꾸면 안됨 -> 바꾸면 영속성 컨텍스트에서 관리되지 못함
  • 테이블, 컬럼명 기본 전략
    • 스프링의 기본전략을 따름 (SpringPhysicalNamingStrategy)
    • 대문자 -> 소문자
    • 카멜케이스 -> 스네이크 케이스
    • . -> _
  • cascade = CascadeType.ALL
    • @*to* 관계에서 옵션을 위와같이 지정하면, 해당 엔티티만 persist해도 같이 반영됨
  • 연관관계 편의 메서드
    • 양쪽 연관관계를 하나의 세터로 묶어서 관리하는 방법
Edit this page
Last updated on