스프링 핵심원리 : 기본편 - 주문 및 할인 정책 도메인 설계

"인프런의 스프링 핵심원리 - 기본편 강의를 듣고 작성한 글 입니다."

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

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

 

주문과 할인 도메인 설계

* 주문과 할인 정책 요구사항

- 회원은 상품을 주문할 수 있다.

- 회원 등급에 따라 할인 정책을 적용할 수 있다.

- 할인 정책은 모든 VIP 는 1000원을 할인해주는 고정 금액 할인을 적용해달라(나중에 변경 될 수 있다.)

- 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전 까지 고민을 미루고 싶다.

최악의 경우 할인을 적용하지 않을 수도 있다.(미확정)

 

* 주문 도메인 협력, 역할, 책임

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

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

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

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

 

참고 : 실제로는 주문 데이터를 DB 에 저장하겠지만, 예제가 너무 복잡해질 수 있어서 생략하고, 단순히 주문 결과를 반환한다.

 

* 주문 도메인 전체

- 위의 이미지를 보면 역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계했다.

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

 

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

- 위의 이미지와 같은 형태로 클래스와 인터페이스가 만들어진다.

 

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

- 회원을 메모리에서 조회하고, 정액 할인 정책(고정 금액) 을 지원해도 주문 서비스를 변경하지 않아도 된다.

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

 

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

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

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

(협력 관계의 재사용과 관련해서는 저번에 작성했던 책 추천 중에 객체지향 관련 교재에서 자세히 나와 있다고 한다.)

 

 

본격적으로 주문, 할인 도메인 설계에 맞춰서 코드를 작성해보자.

hello.core.discount 패키지에 다음과 같이 코드를 작성한다.

- DiscountPolicy.java : 할인 정책 인터페이스

public interface DiscountPolicy {

    // return : 할인 대상 금액
    int discount(Member member, int price);
}

- FixDiscountPolicy.java : 할인 정책 구현 클래스 - 고정 금액 할인

public class FixDiscountPolicy implements DiscountPolicy{

    private int discountFixAmount = 1000; // 1000 원 할인

    @Override
    public int discount(Member member, int price) {
         // VIP 등급의 고객일 경우 1000원 할인
         if (member.getGrade() == Grade.VIP){
             return discountFixAmount;
         }
         else
             return 0;
    }
}

 

hello.core.order 패키지에도 다음과 같이 코드를 작성한다.

- Order.java : 주문 객체 클래스

public class Order {

    private Long memberId;
    private String itemName;
    private int itemPrice;
    private int discountPrice;

    public Order(Long memberId, String itemName, int itemPrice, int discountPrice) {
        this.memberId = memberId;
        this.itemName = itemName;
        this.itemPrice = itemPrice;
        this.discountPrice = discountPrice;
    }

    public int calculatePrice(){
        return itemPrice - discountPrice;
    }

    public Long getMemberId() {
        return memberId;
    }

    public void setMemberId(Long memberId) {
        this.memberId = memberId;
    }

    public String getItemName() {
        return itemName;
    }

    public void setItemName(String itemName) {
        this.itemName = itemName;
    }

    public int getItemPrice() {
        return itemPrice;
    }

    public void setItemPrice(int itemPrice) {
        this.itemPrice = itemPrice;
    }

    public int getDiscountPrice() {
        return discountPrice;
    }

    public void setDiscountPrice(int discountPrice) {
        this.discountPrice = discountPrice;
    }

    @Override
    public String toString() {
        return "Order{" +
                "memberId=" + memberId +
                ", itemName='" + itemName + '\'' +
                ", itemPrice=" + itemPrice +
                ", discountPrice=" + discountPrice +
                '}';
    }
}

- OrderService.java : 주문 서비스 인터페이스

public interface OrderService {

    Order createOrder(Long memberId, String itemName, int itemPrice);
}

- OrderServiceImpl.java : 주문 서비스 구현체

public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);

        // 할인 정책에 대해서는 OrderService 입장에서는 잘 모르니 discountPolicy 에게 일임한다.
        // 이렇게 서로 다른 클래스의 역할에 대해서 서로 모르더라도 기능 수행이 잘 되게끔 하는 것이 설계를 잘한 예시이다.
        // 즉, SOLID 에서 SRP : 단일 책임 원칙을 잘 지킨 것이다.
        // 만약 SRP 원칙이 잘 지켜지지 않았다면, 할인 정책 관련해서 문제가 생겨도 주문 도메인을 같이 고쳐줘야 하는 경우가 생기게 될 것이다.
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}

 

이제 위와 같이 작성한 코드들이 잘 동작하는지 확인해보자.

hello.core 패키지에 다음과 같이 코드를 작성하고 실행해보자.

- OrderApp.java

public class OrderApp {

    public static void main(String[] args) {
        MemberService memberService = new MemberServiceImpl();
        OrderService orderService = new OrderServiceImpl();

        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);
        System.out.println("order = " + order.toString());
        System.out.println("order.calculatePrice = " + order.calculatePrice());
    }
}

결과 :

order = Order{memberId=1, itemName='itemA', itemPrice=10000, discountPrice=1000}
order.calculatePrice = 9000

실행결과 코드가 잘 수행되고 있는 것을 확인할 수 있다.

 

그럼 이제 Junit 을 통해 테스트 코드를 작성해보자.

test 폴더의 hello.core 패키지 아래 order 패키지를 만들고, 다음과 같이 코드를 작성한 후 테스트가 잘 통과되는지 확인해보자.

- OrderServiceTest.java

public class OrderServiceTest {

    MemberService memberService = new MemberServiceImpl();
    OrderService orderService = new OrderServiceImpl();

    @Test
    void createOrder(){
        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);

        Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
    }

}

결과 : 테스트 통과

 

다음 강의 정리글에서는 할인 정책을 지금과 같은 고정 금액 할인이 아니라, 정률(비율) 할인 정책으로 바꿨을 때 현재까지 개발한 게 객체지향적으로 잘 개발된게 맞는지, 클라이언트에게 영향을 주지 않는게 맞는지, 최종적으로 정률 할인 정책으로 구현체를 깔끔하게 변경할 수 있는지를 알아보자.