데일리썽

도메인 모델 패턴의 장점

리포지토리 관계 없이 엔티티 관련 비즈니스 로직 생성

DB 이런거 상관 없이 단위 테스트 -> 그 메서드가 잘 작동하는지 테스트 필요

spring boot test는

여러 엔티티와 기능 통합적으로 잘 작동되는지를 위함

도메인 모델 패턴: 엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 것

엔티티 -> 비즈니스 로직 대부분

서비스 계층 -> 단순히 엔티티에 필요한 요청을 위임하는 역할

JPA, ORM

트랜잭션 스크립트 패턴: 서비스 계층에서 대부분의 비즈니스 로직을 처리

SQL 다룰 때 

유지보수 측면에서 고민

한 프로젝트 내에서도 두가지 패턴이 양립 가능

계층형 구조 사용

controller, web: 웹 계층

service: 비즈니스 로직, 트랜잭션 처리

repository: JPA를 직접 사용하는 계층, 엔티티 매니저 사용

domain: 엔티티가 모여 있는 계층, 모든 계층에서 사용

패키지 구조

• me.seongim
  • domain
  • exception
  • repository
  • service
  • web
  • api

개발 순서: 서비스 리포지토리 계층 개발 -> 테스트 케이스 작성 -> 검증 -> 웹 계층 적용

Getter 모두 열고

Setter 사용X 변경 추적이 어렵다. 변경 지점이 명확하도록 변경을 위한 비즈니스 메서드를 별도로 제공

엔티티의 식별자는 id 사용 PK 컬럼명은 member_id

엔티티는 타입이 있으므로 id만으로 구분 가능

테이블은 타입이 없으므로 구분이 어렵다.

테이블은 테이블 + id

실무에서는 @ManyToMany 사용X

중간 테이블에 컬럼을 추가할 수 없고 세밀하게 쿼리 실행이 어려움

중간 엔티티를 만들고 @ManyToOne @OneToMany로 매핑해서 사용

다대다 매핑 -> 일대다 + 다대일

값 타입은 변경 불가능하게 설계

@Setter 제거하고 생성자에서 값을 모두 초기화해서 변경 불가능한 클래스로 만들어야함

JPA 스펙상 엔티티나 임베디드 타입 (@Embeddable) 은 자바 기본 생성자를 public protected로 설정해야 함

public보다는 protected가 안전

(JPA 구현 라이브러리가 객체를 생성할 때 리플렉션 같은 기술을 사용할 수 있도록 지원하기 위한 제약)

모든 연관관계는 지연로딩(LAZY)으로 설정

즉시로딩(EAGER)은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어려움

JPQL 실행할 때 N+1 문제가 자주 발생

연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용

@XToOne(OneToOne, ManyToOne) 관계는 기본이 즉시로딩이므로 직접 지연로딩으로 설정해야함

컬렉션은 필드에서 초기화

null 문제에 안전함

스프링 부트 신규 설정

cascade = CascadeType.ALL (ALL은 delete까지 모두)

persist(orderItemA)

persist(orderItemB)

persist(order)

= > persist(order)

연관관계 메서드 작성