[SpringBoot JPA 활용 웹 애플리케이션 개발 : 주문 도메인 개발]

구현기능

• 상품 주문
• 주문 내역 조회
• 주문 취소

순서

• 주문 엔티티, 주문상품 엔티티 개발
• 주문 리포지토리 개발
• 주문 서비스 개발
• 주문 검색 기능 개발
• 주문 기능 테스트

주문 상태에 따른 재고 관리

• 취소 시 재고 삭제
• 주문 Entity는 생성될 때 주문이 들어온 것이기 때문에 주문 수량만큼 재고를 줄여줘야 함

정리

> casecade

Entity 관계 설정 중 cascade

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();

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

를 설정해주면 주테이블에 데이터가 변경될 때 이하 테이블들도 같이 데이터가 변경된다(하나의 테이블만 persist해도 나머지 테이블들도 따라서 persist).
하지만 확실하게 테이블 관계가 정해진 상태에서만 cascade 설정을 해주는게 좋고
관계가 Entity 설계가 불확실할경우 차라리 사용하지 않는 것이 낫다.

> Entity 생성메서드

Entity에 생성메서드 하나로 서비스계층에서 Entity 객체생성을 해서 setter를 호출하여 값을 추가하는 등의 소스를 대폭 줄일 수 있다.
다만 혼자 개발하는 것이 아니기 때문에 실컷 만들어둔 Entity의 생성메서드를 사용하지 않고 Entity 객체를 생성해서 비즈니스 로직을 만들 수도 있다.

이를 방지하기 위해 기본생성자의 접근제어자를 protected로 만들어서 다른 곳에서 new 생성을 하지 못하도록 막을 수 있다.

1 : protected Class() {}
2 : @NoArgsConstructor(access = AccessLevel.PROTECTED)

> Entity Class에 비즈니스 로직을 만드는 이유

JPA를 사용했기 때문에 Entity Class 내에서 필드의 값을 변경하면 변경된대로 update쿼리가 실행된다(JPA의 강점).

Mybatis같은 프레임워크를 사용한다면 일일이 쿼리를 작성한 후 하나하나 실행해줘야 하는 불편함이 있다.

그래서 Entity의 값이 변경되는 비즈니스 로직은 Service가 아닌 Entity 내에 작성한다.

- Entity에 비즈니스 로직이 있는 것
[도메인 모델 패턴]
서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할

- Entity에는 비즈니스 로직이 없고 대부분 서비스 계층에서 비즈니스 로직을 처리하는 것
[트랜잭션 스크립트 패턴]
Entity는 getter, setter밖에 없고 보통 SQL을 직접 다루는 스타일에서 사용

각 패턴은 유지보수의 편리함에 맞게 사용하면 된다(=케바케).