이번 시간에는 주문과 할인 도메인을 설계하는 시간을 가졌다.
- 주문과 할인 정책 조건들
주어진 주문과 할인 정책 조건을 살펴보자.
- 회원은 상품을 주문할 수 있고, 회원 등급에 따라 할인 정책을 적용할 수 있다.
- 할인 정책은 모든 VIP는 1,000원을 할인해주는 고정 금액 할인을 적용한다. (하지만, 나중에 변경될 수도 있음.)
- 할인 정책은 변경 가능성이 높기 때문에, 오픈 직전까지 최대한 미루려고 한다.
- 주문 도메인 전체 흐름 예상도
클라이언트가 주문을 생성하면, 그 내용은 회원id, 상품명, 상품 가격을 포함하며,
그 정보들로 주문 서비스에 주문 생성을 요청한다.
주문 서비스는 주문 생성 역할을 하고, 할인은 해주기 위해서는 회원 등급이 필요하기 때문에,
회원 저장소에서 회원을 조회하고, 회원 등급을 확인하고 주문 서비스로 리턴한다.
다시 주문 서비스에서 할인 정책 역할 객체에 할인 적용 가능한지 여부를 요청하고,
주문 서비스로 적용 여부를 리턴한다.
최종적으로 주문 서비스는 할인이 적용된 결과를 클라이언트에 반환한다.
앞서 언급한 것과 같이 주어진 조건중에 확정되지 않은 사항들이 많기 때문에,
역할과 구현을 분리해서 구현하는 방식을 통해서, 자유롭게 구현 객체들을 조립할 수 있게 설계할 수 있다.
크게 역할만 보면, 주문 서비스 역할, 회원 저장소 역할, 할인 정책 역할이 있다.
이렇게 역할을 먼저 만들면, 실제 구현체를 나중에 만들수 있게 된다.
그렇게 되면 나중에 구현체가 바뀌더라도, 예를 들면, 메모리 저장 구현체에서 DB 저장 구현체로 변경이 되더라도,
인터페이스는 변경없이 역할들의 협력 관계를 그대로 재사용 할 수 있다.
- 역할에 따른 구현체
주문 서비스의 역할에는 주문 서비스 구현체를 생성해준다.
회원 저장소 역할에는 1. 메모리 회원 저장소와
2. DB 회원 저장소 구현체를 생성해준다.
할인 정책 역할에는 1. 고정 금액 할인 정책(무조건 1,000원 할인)과
2. 비율에 따른 할인 정책(ex. 10% 할인) 구현체를 분리해서 구현체를 생성해준다.
이렇게 역할과 구현을 구분해서 설계를 하게 되면 앞서 언급한 예시와 같이,
예를 들어, 고정 금액 할인 정책에서 비율에 따른 할인 정책으로 정책이 변경 되더라도,
인터페이스는 유지하고 구현체만 바꿔서 끼워넣을 수 있게 된다~~!
댓글