[Spring] 순수 자바로 회원-주문 서비스 개발하기

- 김영한 님의 '스프링 핵심원리 - 기본편'을 보고 정리한 글입니다 😊

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

---

| 기본 설계

<회원 도메인>

- 기본적으로 인터페이스-클래스 형태로 설계하기.

    - 물론, 실무에서 변경 가능성이 없는 경우에는 바로 클래스로 들어가도 좋다. 지금은 연습이니까!

- 회원은 id, 이름, 등급 정보를 가지고 있다.

    - 이때, 등급 정보는 BASIC / VIP 유저로 나누어져 있다.

- 회원 서비스는 다음과 같은 기능을 제공한다.

    - 회원가입

    - 회원 조회

- 회원 저장소는 메모리 저장소, DB 저장소, 외부 시스템 연동 저장소로 구현할 수 있도록 인터페이스를 설계한다.

---

 

- Spring 내부의 기능을 사용하지 않았기 때문에, 별다른 dependency 추가는 진행하지 않았다.

 

| Member

✔ Domain

[Member.java]

  

    
    
    
    
  
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는 생략하였다.

 

[Grade.java]

  

    
    
    
    
  
public enum Grade {
    BASIC, VIP
}

 

✔ Repository

[MemberRepository.java]

  

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

[MemoryMemberRepository.java]

  

    
    
    
    
  
public class MemoryMemberRepository implements MemberRepository{
    private static Map<Long, Member> store = new ConcurrentHashMap<>();

    @Override
    public void save(Member member) {
        store.put(member.getId(), member);
    }

    @Override
    public Member findById(Long memberId) {
        return store.get(memberId);
    }
}

- 동시성 이슈 때문에 ConcurrentHashMap을 사용하였다. 

 

 

✔ Service

[MemberService.java]

  

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

[MemberServiceImpl.java]

  

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

    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

 

 

✔ Test

[MemberServiceTest.java]

  

    
    
    
    
  
class MemberServiceTest {
    MemberService memberService = new MemberServiceImpl();

    @Test
    public void join() throws Exception {
        // given
        Member member = new Member(1L, "hello", Grade.BASIC);

        // when
        memberService.join(member);

        // then
        Member findMember = memberService.findMember(1L);
        Assertions.assertThat(findMember).isEqualTo(member);
    }
}

- 테스트는 잘 통과한다. 

- 그러나, 기본적으로 MemberService를 선언할 때 MemberServiceImpl() 이라는 구체 클래스에 의존하고 있다.

- 이렇게 되면 구체적인 것에 의존하기 때문에 DIP 위반, 이후 서비스 정책을 변경할 때 클라이언트 코드를 수정해야 하기 때문에 OCP까지 위반하게 된다.

 

- 우선, 위 문제를 기억해두고 주문에 대한 도메인을 설계해보자.

---

- 마찬가지로 역할과 구현을 분리하기 위해, 인터페이스-클래스 형태로 설계한다.

- 주문은 회원 ID, 상품명, 상품 가격에 대한 정보를 가지고 있다.

    - 여기에, 추가적으로 할인된 가격을 리턴해주는 함수를 적용할 예정이다.

- 주문 서비스는 회원을 조회하여 사용자가 지불할 가격을 계산한다. VIP는 할인을 받을 수 있다.

    - 이때, 할인 정책은 정액 할인 정책 (1000원), 정률 할인 정책으로 나뉜다.

---

 

| Discount

[DiscountPolicy.java]

  

    
    
    
    
  
public interface DiscountPolicy {
    int discount(Member member, int price);
}

[FixDiscountPolicy.java]

  

    
    
    
    
  
public class FixDiscountPolicy implements DiscountPolicy{
    private int fixDiscountPrice = 1000;

    // 1000원을 고정으로 할인해주기
    @Override
    public int discount(Member member, int price) {
        if(member.getGrade() == Grade.VIP) {
            return fixDiscountPrice;
        }
        else {
            return 0;
        }
    }
}

- 먼저 정액 할인 정책을 구현하였다. 할인 금액은 1000원이다.

 

 

| Order

✔ Domain

[Order.java]

  

    
    
    
    
  
public class Order {
    private Long memberId;
    private String itemName;
    private int itemPrice;
    private int discountPrice;

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

- 코드에서는 생략했지만, Getter/Setter, 그리고 toString을 넣어주었다.

- 실제 사용자가 지불할 가격을 리턴해주기 위해서 realPrice()라는 메서드를 추가하였다.

 

 

✔ Service

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

🎈 여기서 DiscountPolicy를 주입하는 부분을 잘 보자. 구체 클래스에 의존하고 있다. (뒤에서 설명할 예정)

- id를 바탕으로 회원을 찾아서, 회원에 따른 할인 가격을 리턴받는다.

- 해당 할인가격이 적용된 새로운 주문 인스턴스를 생성한다.

 

 

✔ Test

  

    
    
    
    
  
class OrderServiceTest {
    MemberService memberService = new MemberServiceImpl();
    OrderService orderService = new OrderServiceImpl();

    @Test
    public void createOrder() throws Exception {
        // given
        Member member = new Member(1L, "hello", Grade.VIP);
        memberService.join(member);

        // when
        Order itemA = orderService.createOrder(1L, "itemA", 10000);

        // then
        // 10000원에서 1000원 할인받았으니까 9000원!
        Assertions.assertThat(itemA.realPrice()).isEqualTo(9000);
    }
}

- 테스트 결과 매우 잘 돌아간다.

- 그러나, 위 코드의 경우 마찬가지로 구체 클래스를 의존하고 있다는 단점이 있다.

- 또한, 아직 새로운 할인 정책 - 정률 할인 정책을 적용하지 않은 상태이다.

    - 인터페이스 - 클래스 설계 덕분에 우리는 그냥 정률 할인 정책에 대한 클래스를 생성한 뒤, 적용해주면 된다!

 

---

[RateDiscountPolicy.java]

  

    
    
    
    
  
public class RateDiscountPolicy implements DiscountPolicy{
    private int discountPercent = 10; // 10% 할인

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

- VIP의 경우 10% 할인을 진행해준다.

 

 

✔ Test

[RateDiscountPolicyTest.java]

  

    
    
    
    
  
class RateDiscountPolicyTest {
    RateDiscountPolicy discountPolicy = new RateDiscountPolicy();

    @Test
    public void vip1() throws Exception {
        // given
        Member memberVIP = new Member(1L,"VIP", Grade.VIP);
        Member memberBASIC = new Member(2L, "BASIC", Grade.BASIC);

        // when
        int disVIP = discountPolicy.discount(memberVIP, 10000);
        int disBASIC = discountPolicy.discount(memberBASIC, 10000);

        // then
        Assertions.assertThat(disVIP).isEqualTo(1000);
        Assertions.assertThat(disBASIC).isEqualTo(0);

    }
}

- 마찬가지로 테스트는 잘 돌아간다.

 

- 그러나, 이제 본격적으로 할인정책을 변경하기 위해서는 OrderServiceImpl의 코드를 변경해야 한다.

    - 우리가 기존에 짰던 코드의 경우, DiscountPolicy가 구체 클래스인 FixDiscountPolicy를 의존하기 때문.

    - 이런 식으로 코드를 변경하여 기능을 확장하는 것은 OCP 위반이며, 구체 클래스 의존으로 인한 DIP 역시 위반이다.

 

- 그렇기 때문에, 오직 인터페이스에만 의존하도록 코드를 변경해보자.

    - 그러나, 단순히 = new FixDiscountPolicy(); 를 없애버린다면... NPE가 발생한다.

    - 당연하다. 구현체가 없는데 코드를 실행할 수 없으니까.

 

- 우리는 구현 객체를 대신 생성하고 주입해주는 역할을 해주는 Configuration 파일을 만들어볼 것이다.

    - 관심사의 분리를 위해, Configuration 역시 따로 클래스를 만들어 진행해주는 것이 좋다.

 

---

| 관심사의 분리

- 실행되는 객체들은 어떤 구현체가 주입되는지 알 수 없어야 한다. 그저 각자의 역할에 충실해야 한다.

 

 

[AppConfig.java]

  

    
    
    
    
  
public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
    }

    public OrderService orderService() {
        return new OrderServiceImpl(
                new MemoryMemberRepository(),
                new FixDiscountPolicy()
        );
    }
}

- 코드를 보면, MemberServiceImpl에 대한 구체적인 MemberRepository 구현체를 여기에서 주입하는 걸 볼 수 있다.

    - 실제 동작에 필요한 구현 객체를 생성해준다. 구현 객체를 생성하고 연결하는 건 무조건 AppConfig에서 진행한다!

    - 이런 식으로 생성자를 통해 넣어주는 걸 '생성자 주입' 이라고 한다.

    - 이제, AppConfig에 선언된 memberService()를 사용하면 된다.

- orderService() 역시 세부적인 MemberRepository와 DiscountPolicy에 대한 구현체를 여기에서 넣어주었다.

 

🎈 그러나, 현재 코드에서 MemoryMemberRepository()를 2번 선언하는 등, 중복이 존재하는 걸 볼 수 있다.

     - 이 부분에 대해서는 뒤에서 해결해보도록 하자.

---

✔ 기존에 선언하였던 코드 수정

[MemberServiceImpl.java]

  

    
    
    
    
  
public class MemberServiceImpl implements MemberService{
    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

- memberRepository = new MemoryMemberRepository()를 삭제하고, 생성자를 통해 memberRepository에 주입받도록 하였다.

- 이러면, memberRepository는 더 이상 구현체를 의존하지 않게 된다!

 

[OrderServiceImpl.java]

  

    
    
    
    
  
public class OrderServiceImpl implements OrderService{
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member findMember = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(findMember, itemPrice);
        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}

- 마찬가지로 변경해주었다. OrderServiceImpl은 어떤 할인 정책이 들어오는지, 어떤 DB 접근 기술이 들어오는지 모른다!

- 이제, 각 Impl들은 의존관계에 대한 건 외부에 넘기고, 오직 로직만 실행하면 된다.

🚩 이렇게, DIP를 만족하게 되었다. Impl들은 오직 추상화된 인터페이스에만 의존한다.

 

---

✔ Test 코드 수정

[MemberServiceTest.java]

  

    
    
    
    
  
class MemberServiceTest {

    MemberService memberService;

    @BeforeEach
    public void beforeEach() {
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
    }

    @Test
    public void join() throws Exception {
        // given
        Member member = new Member(1L, "hello", Grade.BASIC);

        // when
        memberService.join(member);

        // then
        Member findMember = memberService.findMember(1L);
        Assertions.assertThat(findMember).isEqualTo(member);
    }
}

- @BeforeEach를 통해, 각 테스트를 호출하기 전에 AppConfig를 선언하여 내부의 memberService를 가져오도록 하였다.

 

[OrderServiceTest.java]

  

    
    
    
    
  
class OrderServiceTest {
    MemberService memberService;
    OrderService orderService;

    @BeforeEach
    public void beforeEach() {
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
        orderService = appConfig.orderService();
    }

    @Test
    public void createOrder() throws Exception {
        // given
        Member member = new Member(1L, "hello", Grade.VIP);
        memberService.join(member);

        // when
        Order itemA = orderService.createOrder(1L, "itemA", 10000);

        // then
        // 10000원에서 1000원 할인받았으니까 9000원!
        Assertions.assertThat(itemA.realPrice()).isEqualTo(9000);

    }
}

---

- 다 좋은데, AppConfig를 조금 더 깔끔하게 관리해보자.

[AppConfig.java]

  

    
    
    
    
  
public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy()
        );
    }

    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }

}

- 재사용이 가능하도록 MemberRepository와 DiscountPolicy에 대한 객체를 만드는 부분을 따로 함수로 뺐다.

    - 이후 변경이 발생하더라도 memberRepository(), discountPolicy() 내부만 바꾸어 주면 된다!

- 이는 곧, Service는 Service만, Repository는 Repository만 관리하게 되어 조금 더 명확하게 역할과 구현 클래스를 한눈에 확인할 수 있다.

 

---

- 지금까지 우리는 SOLID를 만족하기 위해서 여러 가지 시도를 했다.

    - SRP : 관심사를 분리해서 구현 객체의 생성 및 연결은 AppConfig으로, 각 객체는 로직에만 집중하도록.

    - DIP : 구체 클래스에 의존하지 않도록 AppConfig가 대신 클라이언트 코드에 의존관계를 주입하였다.

    - OCP : Fix<->Rate로 할인 정책을 변경하더라도 클라이언트 코드의 변경 없이 AppConfig만 수정하였다.

 

- 이제, 순수 자바만을 이용하지 않고 스프링을 통해서 본격적으로 개발을 시작해보자!