Kim-Baek 개발자 이야기

[스프링 핵심원리] 11. 주문과 할인 도메인 설계 본문

개발/Spring

[스프링 핵심원리] 11. 주문과 할인 도메인 설계

김백개발자 2021. 10. 1. 10:46
김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅

이전에 작성한 내용까지 해서 회원 도메인에 대한 개발이 완료되었다. 하지만 회원만 있다고 서비스가 만들어지는 것은 아니고, 다른 도메인이 필요하다.

그래서 이번에는 주문과 할인 도메인에 대해서 설계를 해보겠다.

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

주문과 할인 정책의 요구사항은 위와 같다.

주문 도메인의 역할에 대해서 살펴보도록 하자.

1. 주문 생성 : 클라이언트 (고객)이 먼저 주문서비스에 주문 생성을 보낸다.

2. 회원 조회 : 주문 서비스는 회원 저장소에서 회원을 조회한다. 이를 통해서 회원의 등급을 찾을 수 있다.

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

4. 주문 결과 반환 : 주문 서비스는 할인이 적용된 결과를 클라이언트에 반환한다.

주문 도메인 전체

처음에는 역할끼리의 의존관계를 보여줬고, 여기서는 구현체까지도 포함해서 보여준다. 이렇게 되니 원하는 구현체를 언제든지 갈아치울 수 있다는 장점이 보인다.

실제로 코드레벨로 보는 클래스 다이어그램이다. 이미 역할에 대한 설계가 끝났기 때문에 클래스  다이어그램도 명확하게 나온다.

서버에 올라갔을 때 보는 객체 다이어그램이다. 메모리 회원 저장소가 사용될 수 있고, 정액 할인 정책이 사용될 수 있다.

구현체를 다르게 변경을 할 수 있다. 메모리가 아니라 DB 회원 저장소를 사용할 수 있고, 정액이 아닌 정률 할인 정책으로도 사용할 수 있다. 하지만 전혀 협력관계는 변경되지 않는 것을 볼 수 있다. 

구현이 아닌 역할을 의존하기 때문에 나오는 좋은 설계의 장점이다.


 

반응형
Comments