스프링 핵심 원리 이해1 - 주문과 할인 도메인 설계

주문과 할인 정책

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

 

클라이언트가 주문 서비스에 제일 먼저 요청을 한다. 예제에서는 상품이라는 item대신 상품명 / 상품 가격을 넘겨주었다.

주문 서비스는 단순히 주문 결과 객체를 만들고 난 후 클라이언트에게 보내는것까지만 적용(실제 DB에 저장하는 것은 생략)

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

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

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

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

 

 

이제 역할과 구현까지 그려보면

주문 도메인 전체

• 클라이언트 역할
• 주문 서비스 역할
• 회원 저장소 역할
• 할인 정책 역할

 

각각의 역할에 구현체가 존재

역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계했다.

덕분에 회원 저장소는 물론이고, 할인 정책도 유연하게 변경할 수 있다.

 

 

실제 이거를 객체레벨로 구현 / 아래 OrderService 구현체 하나만 존재하므로 뒤에 Impl을 붙여줌.

DiscountPolicy가

• 고정할인 정책과
• 정률할인 정책으로 고정이 된다.

 

 

 

 

 

클라이언트가 주문 서비스 구현체를 호출하면 new MemberService를 Impl한 것이고

메모리 회원 저장소는 new MemoryMember 저장소를 호출

정액 할인 정책은 FixDiscountPolicy를 호출

회원을 메모리가 아닌 실제 DB에서 조회하고, 정률 할인 정책(주문 금액에 따라 % 할인)을 지원해도 주문 서비스를 변경하지 않아도 된다.

협력 관계를 그대로 재사용 할 수 있다.

이 뜻은  MemberRepository가 Memory에서 DB로 바뀐다는 뜻이고 

DiscountPolicy가 fixDiscount에서 RateDiscount로 바뀐다는 것이다. 즉 이와같이 바뀌어도 주문 서비스 구현체를 바꿀 필요가 없는 것이다.

 

 

 

정리

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

<출처 김영한: 스프링 핵심 원리 - 기본편 >

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

스프링 핵심 원리 - 기본편 - 인프런 | 강의