주문과 할인 도메인 설계

주문과 할인 정책

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

 

 

주문 도메인 협력, 역할, 책임 
(역할 그림 생략)

1. 주문 생성 : 클라이언트는 주문 서비스에 주문 생성을 요청한다.

2. 회원 조회 : 할인을 위해서는 회원 등급이 필요하다. 그래서 주문 서비스는 회원 저장소에서 회원을 조회한다.

3. 할인 적용 : 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임한다.

4. 주문 결과 반환 : 주문 서비스는 할인 결과를 포함한 주문 결과를 반환한다.

* 실제로는 주문 데이터를 DB에 저장하겠지만, 예제가 너무 복잡해 질 수 있어서 생략하고, 단순히 주문 결과를 클라이언트에 보내는 것 까지만 한다.

역할과 구현까지 그린것 (강의 자료)

역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계했다. 회원 저장소와 할인 정책도 유연하게 변경할 수 있다.!

 

 

interface란 구현체가 딱 하나만 있으면 보통 뒤에 Impl이라 많이 적는다.

 

회원을 메모리에서 조회하고, 정액 할인 정책(고정 금액)을 지원해도 주문 서비스를 변경하지 않아도 된다.
역할들의 협력 관계를 그대로 재사용 할 수 있다.

• ex) DiscountPolicy가 정액 할인에서 정책이 바뀌어도 그래도 주문 서비스 구현체를 바꾸지 않아도 된다.

다이어그램 2로 바꿔도
회원을 메모리가 아닌 실제 DB에서 조회하고, 정률 할인 정책(주문 금액에 따라 % 할인)을 지원해도 주문 서비스를 변 경하지 않아도 된다.
협력 관계를 그대로 재사용 할 수 있다.

 

MemoryMemberRepository 와 FixDiscountPolicy 구현체로 생성해서 사용했다. (주문 도메인 객체다이어그램 1 적용)

 

 

 

이제 테스트를 실행해본다.

 

JUnit 테스트에 작성하기 전에 

main에서 확인 해본 결과

오류없이 잘 되었다.

 

이제 JUnit 으로...

 

테스트에서 System.out 으로 확인하는 것이 아닌

Assertions.assertThat 사용 (이걸 써야 더 편하게  테스트를 만들 수 있다.)

* 테스트 코드의 가독성과 유연성을 높일 수 있으며, 실패 시에 더 자세한 정보를 제공하여 디버깅과 이해를 도울 수 있다고 한다.

 

 

테스트가 잘 되었는지 확인이 되었다.

 

---

 

자동으로 생성된 SpringBootTest는 spirng을 띄우고 해야해서 오래 걸린다.

 

그래서 단위 테스트가 중요하다.

이러한 단위테스트가 수천 개가 있어도 몇 초만에 끝이난다.

여기서의 단위테스트는 spring이나 컨테이너의 도움 없이 순수하게 자바 코드로 테스트를 하는 것이다.

 

 

 

 

여기서 주문 도메인 객체 다이어그램2로 깔끔하게 바꿀 수 있는가?

다음엔 이걸로 변경해보는 것.