DDD - 레포지토리와 모델구현

리포지터리와 모델구현

JPA

모듈 위치

리포지터리 서비스는 도메인에 속하고
구현한 클래스는 인프라스트럭처 영역에 속함

리포지터리

• 인터페이스는 애그리거트 루트를 기준으로 작성함
• 기본기능 구현하기
  • id로 조회하기
  • 저장하기
  • findBy프로퍼티의이름
  • 형태로 사용
• 트랜젝션
  • 메서드 실행이 끝나면 db에 반여하기 위해서 update쿼리를 실행함

리포지터리 구현

• org.springframwork.data.repository.Repository<T,ID>인터페이스 상속
• T -> 엔티티 타입 , ID 식별자 타입
• 규칙에따라서 메서드를 작성
• save, findById, findBy프로퍼티의이름, delete, deleteById

매핑구현

루트는 @Entity로 매핑설정

Value는 Embeddable로 매핑설정

- Value 타입 프로퍼티는 @Embedded로 설정
- @AttributeOberrides로 매핑되는 이름이 다를때 컬럼 이름 변경가능함

기본생성자를 제공해야함

- 하지만 jpa만 사용하기 때문에 protected로 선언

필드접근방식을 사용 @Access(AccessType.FIELD)

- set 메서드를 생성하는 것이 더 안좋음
- 하이버네이트는 @id, @EmveddedId 위치에따라서 필드 메서드를 결정

두개이상의 프로퍼티가 있는 VO는 AttributeContverter이용해야함

- @Converter사용해서 지정하고 AttributeContverter를 상속받아야함
- autoApply true안하면 지정해야함

VO컬렉션

- 따로 테이블을 만들어 참조해서 사용할 것
- @ElementCollection @CollectionTable사용

VO를 하나의 컬럼에 매핑하기

- AttributeConverter 사용
- 새 밸류타입 지정할것
- 밸류타입을 하나의 식별자로 매핑하면 @EmbeddedId 어노테이션
- 식별자가될 밸류타입은 SerialZable 인터페이스를 상속

별도 테이블에 저장되는 VO

- 다른 구성요소중 엔티티가 있으면 의심하기
- 변경상태를 찾아 확인해볼수 있다

VO컬렉션을 @Entity로 매핑하기

- @Ingeritance 어노테이션
- strategy로 SINGLE_TABLE적용
- @DIscriminatorColumn 어노테이션으로 타입구분 칼럼 지정
- 상태변경 기능 x
- 상속받은 클래스는 @Entity와 @Discriminator사용
- 이 VO와는 OnetoMany롷 매칭을 처리
- cascade, orphanRemoveal true지정하기
- clear매서드가 효율적이지않음 그러면 하나의 단일 클래스로 구현하고 if else로 처리해야함

M-N 매핑

- VO 컬렉션 매핑과 동일한 방식
- 연관을 맺는 식별자가 온다는 것이 다름
- @ElementCollection으로 조인테이블도 지워짐

로딩전략

• 루트를 로딩하면 모든 객체가 모여야 완전한 하나여야함을 의미함
• 조회시점에서 완전하기 위해서는 EAGER 사용하면됨
  • 쿼리에 중복을 발생시키기 때무에 성능을 검토해야함
  • 완전한 하나가 꼭 조회 시점이여야 할 필요가 없음
    • 트렌젝션 범위내에서 지연로딩을 허용하기 때문에 문제X
    • 즉 LAZY를 사용해도 됨
  • 애그리거트에 맞게 설정해야함

영속성 전파

• 저장하고 삭제할 때도 하나로 처리
• CascadeType.PERSIST, CascadeType.REMOVE를 설정

식별자 생성기능

• 직접, 도메인 로직으로, DB의 일련번호 사용
• 규칙이 있다면 기능을 분리해야함
• 특정 값의 조합도 규칙임
• 레포지토리인터페이스에 식별자를 생성하는 메서드를 추가하고 구현 하면됨
• 저장한 뒤에 식별자를 구할수 있음

DIP

• 도메인 모델은 구현 기술인 JPA에 의존 X
• 도메인이 래포지토리 즉 인프라에 의존

저수준의 구현기술 변경 거의 X

- 너무과한 대비임
- 타협을 해야한다~~