주문 서비스 개발

구현할 내용

1. 주문

2. 취소

3. 검색(마지막 하이라이트..⭐️)

주문 서비스는 주문 엔티티와 주문 상품 엔티티의 비즈니스 로직을 활용해서 주문, 주문 취소, 주문 내역 검 색 기능을 제공한다.

1. 주문

• 주문

1. 회원 ID, 상품 ID, 주문 수량 이 필요하다. =>MemberRepository, ItemRepository, OrderRepository 필요!

   private final OrderRepository orderRepository;
   private final ItemRepository itemRepository;
   private final MemberRepository memberRepository;

2. 엔티티 조회 : Member와 Item 엔티티를 id로 조회해서 리포지토리에서 가져온다!

   Member member = memberRepository.findOne(memberId);
   Item item = itemRepository.findOne(itemId);

3. 배송정보 생성 : 실제로는 회원 배송지와 실제 배송지는 다르지만 예제 간소화.

   Delivery delivery = new Delivery();
   delivery.setAddress(member.getAddress());

4. 주문상품 생성 : 생성자 메서드 호출⭐️⭐️⭐️⭐️⭐️

   OrderItem orderItem = OrderItem.createOrderItem(item, item.getPrice(), count);

5. 주문 생성 : 생성자 메서드 호출⭐️⭐️⭐️⭐️⭐️

   Order order = Order.createOrder(member, delivery, orderItem);

6. 주문 저장 : Order에서 cascase를 적용함으로써 order를 persist하면 내부의 cascade된 컬렉션과 필드들 모두 함께 persiste된다!

   orderRepository.save(order);//cascade를 적용함으로써 order를 persist하면 order 내부의 컬렉션들(orderitems)과 delivery도 함께 persist된다!
   return order.getId();

• 주문 취소 : 주문 엔티티(orderId) 조회, 주문 취소 메서드 호출 도메인 모델 패턴의 장점이 보인다. 핵심 비즈니스 로직들은 해당 엔티티 내부에서 모두 구현되있기 때문에 외부에서 사용할 땐 해당 비즈니스 로직 메서드를 호출해주기만 하면 된다!

@Transactional
public void cancelOrder(Long orderId) {
  Order order = orderRepository.findOne(orderId);
  order.cancel();
}

<기술 설명>

• cascade 가능 범위

기준 설정 : 리팩토링 할 때 persist 라이프 사이클이 동일하고, 다른 곳에서 참조하는 것이 없다면 cascade 사용 가능.

Order가 Delivery와 OrderItem을 관리한다. 그래서 Order 클래스 내부에서 Delivery와 OrderItem에 대해 cascade를 추가해주면 주문을 저장할 때 orderRepository.save(order)만 해주면 된다. persist하는 라이프 사이클이 동일하기 때문에

참조하는 주인이 private일 때만 써야한다. Delivery와 OrderItem는 Order만 참조하고 있다. 다른 것들이 참조하는 경우가 아닐 때. 근데 만약에 Delivery나 OrderItem가 다른 곳에서도 많이 참조하는 거라면 cascade를 사용하면 안 된다. 그러면 Order를 지울 때 Delivery도 함께 다 지워지기 때문이다! 이럴 땐 별도의 Repository를 생성해서 persist를 개별적으로 해주어야한다.

• 기본 생성자 protected 설정, 외부 생성 방지 생성로직을 일관되게 해야한다. 그렇지 않으면 필드를 추가하거나 수정할 때 유지보수가 어려워지기 때문이다!

@NoArgsConstructor(access = AccessLevel.PROTECTED)

protected OrderItem() {}

• JPA 장점 데이터를 변경하면 외부에서 DB도 함께 변경해주어야한다. 하지만 JPA를 활용하면 데이터만 바꿔주면 dirtyCheck(변경 내역 감지)가 일어나면서 DB에 업데이트 쿼리가 들어간다!

• 도메인 모델 패턴 주문 서비스의 주문과 주문 취소 메서드를 보면 비즈니스 로직 대부분이 엔티티에 있다. 서비스 계층 은 단순히 엔티티에 필요한 요청을 위임하는 역할을 한다. 이처럼 엔티티가 비즈니스 로직을 가지고 객체 지 향의 특성을 적극 활용하는 것을 도메인 모델 패턴이라 한다.

• 트랜잭션 스크립트 패턴 엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분 의 비즈니스 로직을 처리하는 것

어떤 것이 좋다고 할 수 없다. 트레이드오프되는 것이기 때문에 상황에 따라 트랜잭션 스크립트 패턴이 좋을 때도 있고, 상태와 행위를 모아놓은 도메인 주도 설계가 좋을 때도 있다. 한 프로젝트 내에서도 트랜잭션 스크립트 패턴과 도메인 주도 패턴이 양립할 때도 있다.