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

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

김영한 의 검색 결과 - 인프런 | 강의

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

 

# 비즈니스 요구사항

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

확정난건 없지만, 시간은 없다. 우리는 개발을 시작해야 한다.

# 회원

# 회원 도메인 설계

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

도메인이 뭐죠

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

도메인[주문, 회원, 결제, 배송]의 연관 관계를 표현한 그림

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

클래스 다이어그램. 객체를 Entity, 객체가 가진 값들을 Value라고 부른다.

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

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

협력관계, 역할과 책임을 잘 생각해서 구현하자.

---

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

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

자바 클래스의 관계를 보여주는 그림

 

---

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

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

만들어진 객체들이 실제 서비스에서 동작하는 그림

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

• 도메인 (Member, Grade)

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 생략 ...
}

 

• 서비스 (MemberService, MemberServiceImpl)

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

 

• 저장소 (MemberRepository, MemoryMemberRepository)

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가 잘 지켜지고 있는가?

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

저장소 구현체의 변경이 클라이언트(MemberService) 코드에 영향을 끼친다.

 

---

# 주문과 할인

# 주문과 할인 도메인 설계

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

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

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

* 실제 서비스에서는 DB에 저장하겠지만, 예제 코드에서는 생략하였다.

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

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

저장소를 바꾸거나 할인 정책을 바꾸더라도 '주문 서비스'를 변경할 필요가 없다. 즉 역할들의 협력관계를 그대로 재사용 할 수있다.

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

주문도메인 (Order)

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

 주문 서비스 역할, 인터페이스(OrderService)

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

할인 정책 서비스 역할 (DiscountPolicy)

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' 의 구현 객체를 대신 생성하고, 주입해주면 된다. 이것이 바로 관심사의 분리이다.

 

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