영속성 컨텍스트(persistence context) 쉽게 말하면 엔티티를 영구 저장하는 환경이다. 즉, 엔티티 메니저로 엔티티를 저장하거나 조회하면 엔티티메니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다. 영속성 컨텍스트는 엔티티 메니저 당 하나씩 할당한다 엔티티의 생명주기 엔티티는 4가지 상태가 존재한다. - 비영속 : 영속성 컨텍스트와 전혀 관계가 없는 상태 순수한 객체 상태이며, 아직 저장되지 않음. DB와 전혀 관련 없는 객체 - 영속 : 영속성 컨텍스트에 저장된 상태 - 준영속 : 영속성 컨텍스트에 저장되었다가 분리된 상태 영속성 컨텍스트가 관리하지 않으므로 거의 비영속 상태에 가깝고, 그렇기에 지연 로딩을 할 수 없다. 하지만, 식별자 값을 가지고 있다는 특징이 있다. - 삭제 : 삭제된..

엔티티 메니저 이름 그대로 엔티티를 관리하는 관리자다. 엔티티를 저장, 수정, 삭제, 조회 등 엔티티와 관련한 모든 일을 처리한다. JPA 대부분 기능은 엔티티 메니저에서 제공한다. 엔티티 메니저는 DB 커넥션과 밀접한 관계가 있으므로 스레드 간 공유하거나 재사용을 하면 안 된다. 엔티티 메니저는 엔티티 메니저 팩토리를 통해 생성된다. 엔티티 메니저 팩토리 이름 그대로 엔티티 메니저를 만드는 공장이다. 데이터 커넥션 풀도 생성할 정도로 생성 비용이 아주 크다. 즉, 엔티티 메니저 팩토리는 애플리케이션 전체에서 딱 한 번만 생성하고 공유해서 사용해야 한다.

# 시작에 앞서 CQRS : 명령 모델과 조회 모델을 분리하는 패턴. 상테(데이터) 변경 기능 구현시에는 명령 모델, 데이터를 보여주는 기능을 구현할 때는 조회 모델 사용 # 검색을 위한 스펙 스팩 Specification : 검색 조건을 다양하게 조합해야 할 때 사용할 수 있는 것 agg는 애그리거트 루트, agg는 검색 결과로 리턴할 데이터 객체가 됨. 만약 리포지터리가 메모리에 모든 애그리거트를 보관하고 있다면 다음과 같이 사용 가능하나, 실제로는 모든 데이터를 메모리에 저장을 못하기에 사실상 위와 같이 사용 불가능 실제 스펙은 사용하는 기술에 맞춰 구현하게 됨 # 스프링 데이터 JPA를 이용한 스펙 구현 JPA 크리테리아 API를 같이 이용 스펙은 and 혹은 or, where 등으로 조합이 가능..

매핑 구현 - 애그리거트와 JPA 매핑을 위한 기본 규칙 - 애그리거트 루트는 엔티티이므로 @Entitiy로 매핑 설정 - 벨류는 @Embeddedable로 매핑 설정 - 벨류 타입 프로퍼티는 @Embedded로 매핑 설정 - 타 애그리거트는 ID로 참조 AttributeConverter - int, long, String, LocalDate 같은 타입은 DB 테이블에 한 개의 컬럼에 매핑됨. - 이와 비슷하게 벨로타입의 프로퍼티를 한 개의 컬럼에 매핑해야할 때도 있음. - AttributeConverter을 통해 벨류 타입과 칼럼 데이터 간의 변환 처리 가능 - 벨류 컬렉션을 별도 테이블로 매핑시에는 @ElementCollection과 @CollectionTable을 함께 사용 - List에 자체 인덱..