#3 스프링 핵심 원리 - 기존의 불편한 설계 방식

해당 글은 김영한님의 인프런 강의를 공부하고 정리한 내용입니다.

스프링 없이 순수한 자바코드로 비즈니스 서비스를 만들어보자.

# 비즈니스 요구사항

다음과 같은 기획자의 비즈니스 요구사항이 있다고 가정해보자. 요구사항 중에는 아직 확정나지 않았거나, 개발 도중 변경할 수도 있는 내용들이 포함되어 있다.

# 회원

# 회원 도메인 설계

우선, 비즈니스의 핵심인 회원의 도메인에 대해 설계를 시작해보자.

도메인이 뭐죠

더보기

해결하고자 하는 문제 및 관심사를 도메인(Domain)이라고 표현한다. 예를 들어 서점 서비스를 만들고자 한다면, 도메인은 다음과 같이 구성할 수 있다.

이렇게 만든 도메인 모델을 바탕으로 구체화하여 클래스 다이어그램과 객체 다이어그램을 만든다. 

현재 주어진 회원 도메인의 요구사항은 아래와 같다.

• 회원을 가입하고 조회할 수 있다
  ⇒ 회원가입과 조회기능을 제공하는 [회원 서비스] 를 만든다.
• 회원은 일반과 VIP 두 가지 등급이 있다.
  ⇒ 회원 도메인은 등급 정보를 가진다. Enum 을 이용하여 등급을 나타내는 타입을 만든다.
• 회원 데이터 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다.(미확정)
  ⇒ 회원 데이터를 조회하는 역할, [회원 저장소] 인터페이스를 만든다.

이렇게 만든 도메인을 이용하여 객체 & 클래스 다이어그램을 만들어보자.

• [회원 서비스]는 MemberService 인터페이스(역할)을 만들고 MemberServiceImpl로 구현한다.
• [회원 저장소]는 MemberRepository 인터페이스(역할)을 만들고 각 저장소별 구현체를 구현한다. 

도메인과 클래스 다이어그램이 완성되었다면, 실제 서버에서 객체간 참조가 어떻게 되는지를 그린다. 이를 객체 다이어그램이라 하며 실제 서비스가 어떻게 동작 되는지 한눈에 볼 수 있다.

• 클라이언트는 회원서비스를 호출하고, 회원 서비스는 회원 저장소를 참조하여 비즈니스 로직을 실행합니다.

이를 바탕으로 직접 작성한 자바코드는 다음과 같다.

public enum Grade {
    BASIC,
    VIP
}

public class Member {
    private Long id;
    private String name;
    private Grade grade;
 
    public Member(Long id, String name, Grade grade) {
        this.id = id;
        this.name = name;
        this.grade = grade;
    }
 
    // ... getter setter 생략 ...
}

public interface MemberService {
    void join(Member member);
 
    Member findMember(Long memberId);
}

public class MemberServiceImpl implements MemberService {
    public final MemberRepository memberRepository = new MemoryMemberRepository();
 
    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }
 
    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

public interface MemberRepository {
    void save(Member member);
 
    Member findById(Long memberId);
}

public class MemoryMemberRepository implements MemberRepository {
    public static Map<Long, Member> store = new HashMap<>();
 
    @Override
    public void save(Member member) {
        store.put(member.getId(), member);
    }
 
    @Override
    public Member findById(Long memberId) {
        return store.get(memberId);
    }
}

# 회원 도메인 실행과 테스트

작성한 코드들이 잘 작동하는지 서비스 계층부터 테스트 코드를 작성해서 확인해보자.

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
 
// 앱 진입점
public class MemberApp {
    public static void main(String[] args) {
        MemberService memberService = new MemberServiceImpl();
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);
 
        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member.getName());
        System.out.println("findMember = " + findMember.getName());
    }
}

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
 
// JUnit을 이용한 테스트
class MemberServiceTest {
    MemberService memberService = new MemberServiceImpl();
 
    @Test
    void join() {
        //given
        Member member = new Member(1L, "memberA", Grade.VIP);
 
        //when
        memberService.join(member);
        Member findMember = memberService.findMember(1L);
 
        //then
        Assertions.assertThat(member).isEqualTo(findMember);
    }
}

# 회원 도메인 평가하기

회원 도메인의 설계와 테스트를 성공했다. 자 그렇다면 해당 코드는 객체지향에서 말하는 SOLID 원칙의 OCP, DIP를 만족하고 있는가? 다형성이 잘 설계된 코드일까?

• 회원 저장소로 MemberRepository를 사용할 때 나중에 저장소를 변경할 때 OCP 원칙이 지켜질 수 있는가?
• DIP가 잘 지켜지고 있는가?

아니다. 의존관계가 인터페이스와 구현체에 모두 있다. 일단은 넘어가도록 하고, 주문과 할인을 설계해보자.

# 주문과 할인

# 주문과 할인 도메인 설계

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

주문과 할인에 대한 정책과 요구사항을 분석해보자. 회원은 주문을 할 수 있는데, 회원의 등급에 따라 상품에 할인이 적용될 수 있다. 이를 정리하면 아래 4가지로 만들 수 있다.

• 주문 생성: 클라이언트는 주문 서비스에 주문 생성을 요청한다.
• 회원 조회: 할인을 위해서 회원 등급을 알아야하기에 회원을 조회한다.
• 할인 적용: 회원 등급에 따른 할인여부와 할인 금액을 알기 위해 해당 책임을 할인 정책 역할에 위임한다.
• 주문 결과 반환: 주문 서비스는 할인 결과를 포함한 주문 결과를 반환한다.

만들어논 설계를 바탕으로 클래스의 구성도를 그려보자. 객체를 직접 연결하는게 아닌 역할(인터페이스)와 구현(객체)를 분리한다. 이렇게 "역할과 구현을 분리"해서 설계하여야 [회원 저장소]나 [할인 정책]을 유연하게 변경할 수 있다. 

도메인과 클래스를 바탕으로 객체간의 참조 관계를 그린다.

주문과 할인정책에 관련하여 도메인과 역할(인터페이스)을 차례대로 생성해보자. 실제 설계에서는 '상품'도 도메인으로 만들어 객체 설계를 해야하지만 이번 예제에서는 간단하게 상품은 이름과 가격만 데이터로 받도록 만들었다.

package hello.core.discount;
 
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 interface DiscountPolicy {
    /**
     * @return 할인 대상 금액
     */
    int discount(Member member, int price);
}

인터페이스 설계를 완료했다면, 바로 아래의 구현체를 만들어도 되지만, 잠깐 넘어가서 테스트코드부터 작성해보자. 이렇게 테스트 코드를 먼저 작성하면 어떤 이점이 있을까?

//DiscountPolicy 구현체
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;
        }
        return 0;
    }
}

//OrderSevice 구현체
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 discount = discountPolicy.discount(member, itemPrice);
 
        return new Order(memberId, itemName, itemPrice, discount);
    }
}

# 주문과 할인 도메인 구현과 테스트

@DisplayName("OderService 클래스의")
class OrderServiceTest {
    private Member basicMember;
    private Member vipMember;
 
    private OrderService orderService;
    private MemberService memberService;
 
    @BeforeEach
    void setup() {
        orderService = new OrderServiceImpl();
        memberService = new MemberServiceImpl();
 
        basicMember = new Member(1L, "BASIC", Grade.BASIC);
        vipMember = new Member(2L, "VIP", Grade.VIP);
 
        memberService.join(basicMember);
        memberService.join(vipMember);
    }
 
    @Nested
    @DisplayName("createOrder 메소드는")
    class Describe_createOrder {
        @Nested
        @DisplayName("일반 등급의 회원이 10000원짜리 물건의 주문을 생성할 경우 가격은")
        class Context_with_create_order_from_basic_member {
            @DisplayName("제품의 물건 가격 그대로 생성된다.")
            @Test
            void it_is_original_price() {
                //when
                Order order = orderService.createOrder(basicMember.getId(), "item", 10000);
 
                //then
                assertThat(order.calculatePrice()).isEqualTo(10000);
            }
        }
 
        @Nested
        @DisplayName("VIP등급의 회원이 10000원짜리 물건의 주문을 생성할 경우 가격은")
        class Context_with_create_order_from_vip_member {
            @DisplayName("제품의 물건 가격 그대로 생성된다.")
            @Test
            void it_is_discounted_price() {
                //when
                Order order = orderService.createOrder(vipMember.getId(), "item", 10000);
 
                //then
                assertThat(order.calculatePrice()).isEqualTo(9000);
            }
        }
    }
}

# 이 코드는 OCP와 DIP를 지키고 있는 설계일까?

아래와 같이 새로운 할인 정책을 만든다고 가정해보자.

악덕 기획자: 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액 당 할인하는 정률% 할인으로 변경하고 싶어요.

예를 들어서 기존 정책은 VIP가 10000원을 주문하든 20000원을 주문하든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10000원 주문시 1000원을 할인해주고, 20000원 주문시에 2000원을 할인해주는 거에요!

순진 개발자: 제가 처음부터 고정 금액 할인은 아니라고 했잖아요. (좋지않은 커뮤니케이션의 예1)

악덕 기획자: 애자일 소프트웨어 개발 선언 몰라요? “계획을 따르기보다 변화에 대응하기를”

순진 개발자: … 

애자일 소프트웨어 개발이란?

더보기

위에서 구현과 역할을 구분해놨기에 단순히 생각하면 아래와 같이 새로운 할인 객체를 만들고, 테스트 해본 뒤 적용시켜주면 된다. 기존의 개발방식보다는 훨씬 간단하긴 하다. 한줄만 바꾸면 되니까

public class OrderServiceImpl implements OrderService {
    
    private final MemberRepository memberRepository = new
            MemoryMemberRepository();
 
	// 할인정책 구현부 변경!
//  private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
    
    @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);
    }
}

@ 숨겨진 문제점

• 우리는 역할과 구현을 충실하게 분리했다. OK
• 다형성도 활용하고, 인터페이스와 구현 객체를 분리했다. OK
  
  
• OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수했다..?
  -> 그렇게 보이지만 사실은 아니다.
  
  
• DIP: 의존성. 주문 클라는( OrderServiceImpl )는 DiscountPolicy 인터페이스만 의존하니 지킨거 아닌가?
  - 클래스를 다시보자. 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다.
  

  

  
  -> 추상(인터페이스) 의존: DiscountPolicy
  -> 구체(구현) 클래스: FixDiscountPolicy , RateDiscountPolicy
  
  
• OCP: 변경하지 않고 확장할 수 있게 설계해야 한다.
  지금 코드는 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 준다! 따라서 OCP를 위반한다.
  

  

결국 구현체 코드가 바뀌면 다른 코드를 변경해야함은 변함없다. 조금 더 편해졌을 뿐, 역할과 구현이 분리되지 않으면 OCP와 DIP같은 객체지향 원칙을 지키지 못한다는 말이다.

@ 아니 그러면 어떻게 OCP, DIP를 구현해요?

정말 간단하다. 인터페이스(역할)이 아닌 구현부분을 코드에서 제거하면 된다. 그럼 DIP를 쉽게 지킬 수 있다.

//private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
private final DiscountPolicy discountPolicy;

??????????? 그럼 구현체가 없는데 어떻게 코드를 실행시켜요? null을 실행시켜요?

@ 해결방안

이 문제를 해결하려면 누군가 클라이언트인 'OrderServiceImpl'에 'DiscountPolicy' 의 구현 객체를 대신 생성하고, 주입해주면 된다. 이것이 바로 관심사의 분리이다.

글이 길어져, 다음 글에 계속 이어서 작성하겠습니다.