[스프링 핵심 원리 - 기본편] 스프링 핵심 원리 이해1 - 예제 만들기(2)

주문과 할인 도메인 설계

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

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

  

  • 1. 주문 생성: 클라이언트는 주문 서비스에 주문 생성을 요청한다.
  • 2. 회원 조회: 할인을 위해서는 회원 등급이 필요하다. 그래서 주문 서비스는 회원 저장소에서 회원을 조회한다.
  • 3. 할인 적용: 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임한다.
  • 4. 주문 결과 반환: 주문 서비스는 할인 결과를 포함한 주문 결과를 반환한다.

• 주문 도메인 전체

  

  • 역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계되어있어 회원 저장소, 할인 정책이 변경되어도 유연하게 변경할 수 있다.

 

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

  

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

  

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

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

  

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

 

주문과 할인 도메인 개발

• 할인 정책 인터페이스

  public interface DiscountPolicy {
  
      /**
       * @return 할인 대상 금액
       */
      int discount(Member member, int price);
  }

• 정액 할인 정책 구현체

  public class FixDiscountPolicy implements DiscountPolicy {
  
      private int discountFixAmount = 1000; // 1000원 할인
  
      @Override
      public int discount(Member member, int price) {
          if(member.getGrade() == Grade.VIP) {
              return discountFixAmount;
          } else{
              return 0;
          }
      }
  }

• 주문 엔티티

  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 +
                  '}';
      }
  }

• 주문 서비스 인터페이스

  public interface OrderService {
      Order createOrder(Long memberId, String itemName, int itemPrice);
  }

• 주문 서비스 구현체

  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);
          int discountPrice = discountPolicy.discount(member, itemPrice);
  
          return new Order(memberId, itemName, itemPrice, discountPrice);
      }
  }

  • 주문 생성 요청이 오면, 회원 정보를 조회하고, 할인 정책을 적용한 다음 주문 객체를 생성해서 반환한다. 메모리 회원 리포지토리와, 고정 금액 할인 정책을 구현체로 생성한다.

• 주문과 할인 도메인 테스트

  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);
      }
  }

 

새로운 할인 정책 개발

• 기존의 정액 할인 정책에서 정률 할인 정책으로 변경

• 정률 할인 정책 구현체

  public class RateDiscountPolicy implements DiscountPolicy{
  
      private int discountPercent = 10;
  
      @Override
      public int discount(Member member, int price) {
          if(member.getGrade() == Grade.VIP){
              return price * discountPercent / 100;
          }else {
              return 0;
          }
      }
  }

• 정률 할인 정책 테스트

  class RateDiscountPolicyTest {
  
      RateDiscountPolicy discountPolicy = new RateDiscountPolicy();
  
      @Test
      @DisplayName("VIP는 10% 할인이 적용되어야 한다")
      void vip_o() {
          //given
          Member member = new Member(1L, "memberVIP", Grade.VIP);
          //when
          int discount = discountPolicy.discount(member, 20000);
          //then
          assertThat(discount).isEqualTo(2000);
      }
  
      @Test
      @DisplayName("VIP가 아니면 할인이 적용되지 않아야 한다")
      void vip_x() {
          //given
          Member member = new Member(1L, "memberBASIC", Grade.BASIC);
          //when
          int discount = discountPolicy.discount(member, 20000);
          //then
          assertThat(discount).isEqualTo(0);
      }
  }

 

기존 할인 정책을 새로운 할인 정책으로 변경 시 문제점

• 할인 정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 고쳐야 한다.

  public class OrderServiceImpl implements OrderService {
  // private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
     private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
  }

 

• 객체지향 설계 원칙을 충실히 준수한 것처럼 보이지만 사실은 그렇지 않기 때문이다.
  • DIP 위반으로 인해 OCP 위반도 동시에 발생

• DIP: 주문서비스 클라이언트( OrderServiceImpl )는 DiscountPolicy 인터페이스에 의존하면서 DIP를 지킨 것 같지만 클래스 의존관계를 분석해보면 추상(인터페이스)뿐만 아니라 구체(구현) 클래스에도 의존하고 있다. (DIP 위반)
  • 추상(인터페이스) 의존: DiscountPolicy
  • 구체(구현) 클래스: FixDiscountPolicy , RateDiscountPolicy
  
  
  • 기대했던 의존관계

    

  • 실제 의존관계

    

    • 실제 코드를 보면 클라이언트(OrderServiceImpl)가 DiscountPolicy 인터페이스 뿐만 아니라 FixDiscountPolicy 인 구체 클래스도 함께 의존하고 있다. (DIP 위반)
  • 할인 정책 변경

    

    • 기대했던 의존관계와 실제 의존관계가 다른것을 확인할 수 있다. 이 차이점으로 인해 FixDiscountPolicy 를 RateDiscountPolicy 로 변경하는 순간 OrderServiceImpl 의 소스 코드도 함께 변경해야 한다. (OCP 위반)

• OCP: 지금 위의 구조로 보았을 때, 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 준다. (OCP 위반)

 

문제 해결 방법

• 클라이언트 코드인 OrderServiceImpl 은 DiscountPolicy 의 인터페이스 뿐만 아니라 구체 클래스도 함께 의존한다. 그래서 구체 클래스를 변경할 때 클라이언트 코드도 함께 변경해야 한다.

• DIP를 위반하지 않게 인터페이스에만 의존하도록 의존관계를 변경하면 된다.

  

• 인터페이스에만 의존하도록 코드 변경

  public class OrderServiceImpl implements OrderService {
   //private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
     private DiscountPolicy discountPolicy;
  }

  • 인터페이스에만 의존하도록 설계와 코드를 변경했지만 구현체가 없어서 코드를 실행할 수 없다. 즉, NPE(null pointer exception)가 발생한다.

• 해결방안 : 이 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpl 에 DiscountPolicy 의 구현 객체를 대신 생성하고 주입해주어야 한다.

---

[참고자료]

스프링 핵심 원리 - 기본편, 김영한