Practice2. 주문과 할인 도메인 설계

비즈니스 요구사항

---

회원

• 회원을 가입하고 조회할 수 있다.
• 회원은 일반과 VIP 두 가지 등급이 있다.
• 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)

주문과 할인 정책

• 회원은 상품을 주문할 수 있다.
• 회원 등급에 따라 할인 정책을 적용할 수 있다.
• 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.)
• 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정)

 

주문 도메인 설계

---

주문 도메인 관계도

1. 주문 생성 : 클라이언트에서 주문 서비스에 주문 생성 요청
2. 회원 조회 : 등급 별 할인 여부 확인을 위해 회원 저장소에서 회원 조회
3. 할인 적용 : 주문 서비스에서 등급 별 할인 차등 적용을 할인 정책에 위임
4. 주문 결과 반환 : 주문 서비스에서 할인 결과를 포함한 주문 결과 반환

*실제 제품은 주문 데이터를 DB에 저장하지만 예제에서는 생략하고 단순 주문 결과만 반환한다.

 

 

주문 도메인 클래스 다이어그램

주문 도메인 객체 다이어그램(참조 관계)

메모리에서 회원 조회, 할인 정책을 지원하더라도 주문 서비스 변경x 역할 간 협력 관계 재사용 가능

DB에서 회원 조회, 할인 정책을 지원하더라도 주문 서비스 변경x 역할 간 협력 관계 재사용 가능

 

구현 클래스

---

할인 정책(정책/정책 구현체)

 

• ⓘ DiscountPolicy
• ⓒ FixDiscountPolicy
  • 할인 금액 선언
  • 할인 여부 확인 후 할인 금액 리턴

주문 엔티티

• ⓒ Order
  • 주문 생성에 필요한 값 선언(memberId,itemName,itemPrice,discountPrice)
  • 할인 금액 적용하여 계산
  •  

주문 서비스(서비스/서비스 구현체)

• ⓘ OrderService
  • Order createOrder(Long memberId,String itemName,itemPrice)
• ⓒ OrderServiceImpl
  • 특정 회원 조회 후 해당 회원 등급으로 할인 정책 적용한 Order 리턴

주문 도메인 실행(main)

• ⓒ OrderApp
  • 서비스 실행

 

 

*JUnit test

• 애플리케이션 로직으로 테스트 하지말고 해당 로직을 가져와 JUnit 테스트를 진행하자
• 실행 방식은 해당 로직을 Assertions.assertThat() 를 통해 true/false 검증