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

이어서 비즈니스 요구사항에 따라 주문과 할인 도메인을 설계한다.

 

정의된 비즈니스 요구사항에 따르면, 주문과 할인 정책은 다음과 같다.

https://debuggingworld.tistory.com/83

5. 비즈니스 요구사항과 회원 도메인 설계

 

 

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

 

 

 

주문과 할인 도메인 설계

 

주문 도메인 협력관계

복습해보면, 도메인 협력 관계는 기획자 등의 관계자도 함께 보는 일반적인 도식이었다.

주문 도메인 협력관계 (강의자료 발췌)

 

회원이 클라이언트를 통해 상품을 주문하는 과정은 다음과 같다.

1. 주문 생성

- 클라이언트가 주문 서비스에게 주문 생성을 요청한다.

- 이 때 회원  id, 상품명, 상품가격을 전달한다.

- 일반적으로 상품에 대한 정보 역시 별도의 저장소를 통해 관리하지만, 예제 코드에서는 생략되었다.

 

2. 회원 조회

- 비즈니스 요구사항에 따르면 할인 정책이 존재한다.

- 할인 정책을 적용하기 위해서는 회원 등급이 필요하므로, 주문 서비스에서는 주문 생성 요청이 들어오면 먼저 회원 저장소에서 회원을 조회한다.

 

3. 할인 적용

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

 

4. 주문 결과 반환

- 주문 서비스는 할인 결과를 반영하여 클라이언트에게 주문 결과를 반환한다.

- 실제로는 주문 데이터를 DB에 저장해야 하지만, 역시 예제 코드에서는 생략되었다.

 

 

각 역할에 대한 구현체를 명시한 도메인 전체는 다음과 같다.

주문 도메인 전체 (강의자료 발췌)

주문 도메인의 전체 내용을 보면, 역할과 구현을 분리함으로써 나타나는 특징이 도드라진다.

구현 객체를 자유롭게 조립할 수 있게 되어 회원 저장소와 할인 정책을 유연하게 변경할 수 있다.

 

메모리/DB 회원 저장소와 정액/정률 할인 정책을 자유롭게 조합할 수 있게 되었다.

 

 

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

복습해보면, 클래스 다이어그램은 개발자가 구체화하여 설계하는 다이어그램이다.

개발 과정에서 실제로 구현할 인터페이스, 구현 클래스 등이 명시된다.

 

도메인 협력 관계를 바탕으로 클래스 다이어그램을 다음과 같이 구성할 수 있다.

주문 도메인 클래스 다이어그램 (강의자료 발췌)

 

 

주문 도메인 객체 다이어그램

객체 다이어그램은 실제 런타임에서 실제로 생성되고 참조되는 객체들을 표현한 것이다.

따라서 구현체를 무엇으로 결정했는지에 따라 여러 객체 다이어그램이 구성될 수 있다.

 

1) 메모리 회원 저장소, 정액 할인 정책을 적용한 경우

객체 다이어그램 1 (강의자료 발췌)

클래스 다이어그램에 따르면 주문 서비스의 구현체는 유일하다.

주문 서비스는 회원 저장소를 통해 회원을 조회하고, 회원 정보를 할인 정책에게 넘긴다.(할인 여부를 할인 정책에게 위임한다)

회원 정보는 메모리 회원 저장소에 저장되어 있으며, 할인 정책은 정액 할인 정책을 적용하여 할인 여부(혹은 금액)을 결정한다.

최종적으로 주문 서비스는 주문 결과를 생성하여 클라이언트에게 전달한다.

 

 

2) DB 회원 저장소, 정률 할인 정책을 적용한 경우

객체 다이어그램 2 (강의자료 발췌)

마찬가지로 주문 서비스는 회원 저장소를 통해 회원을 조회하고, 회원 정보를 할인 정책에게 넘긴다.

이 때 회원 저장소는 DB로 구현되어있고, 할인 정책은 정률 할인 정책을 적용하여 할인 여부(혹은 금액)을 결정한다.

최종적으로 주문 서비스는 주문 결과를 생성하여 클라이언트에게 전달한다.

 

두 경우를 살펴보면, 회원 저장소와 할인 정책이 변경되어도 주문 서비스는 변하지 않는다.

객체 지향적으로 프로그램을 설계했기 때문에 가능한 일이며, 협력 관계를 그대로 재사용할 수 있어 소프트웨어 생산성이 높아진다.