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

본 게시글은 김영한 강사님의 [스프링 핵심 원리 - 기본편]을 수강하며 작성한 글입니다.

 

스프링을 사용하지 않고 순수한 자바로만 개발을 해보자.
이를 통해 왜 스프링이 필요한지 깨달아야 한다.

 

프로젝트 환경 구성

---

• Language: Java 11
• IDE: IntelliJ

 

비즈니스 요구사항

---

• 회원
  • 회원 가입과 조회 기능이 있다.
  • 회원은 일반과 VIP 등급이 있다.
  • 회원 데이터는 자체 DB를 구축하거나 외부 시스템과 연동할 수 있다. (미정)
• 주문과 할인 정책
  • 회원은 상품을 주문할 수 있다.
  • 회원 등급에 따라 할인 정책을 적용할 수 있다.
  • 할인 정책은 모든 VIP는 1000원을 할인하는 고정 금액 할인을 적용해달라. (나중에 변경될 수 있다.)
  • 할인 정책은 변경될 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 있다. (미정)

요구사항을 보면 회원 데이터와 할인 정책같은 부분은 당장 결정하기 어려운 부분이다. 그렇다고 기획이 확정될 때까지 개발을 미룰 순 없다.

그러니 인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계해보자.

 

회원 도메인 설계

---

회원 도메인 협력 관계

• 역할: 클라이언트, 회원 서비스, 회원 저장소
• 구현: 메모리 회원 저장소, DB 회원 저장소, 외부 시스템 연동 회원 저장소

개발 용으로 메모리 회원 저장소 구현체를 사용하다가 회원 데이터를 저장할 장소를 결정하게 될 경우 구현체를 바꿀 계획이다.

 

회원 클래스 다이어그램

 

회원 객체 다이어그램

MemberRepository 역할에 MemoryMemberRepository를 넣을지 DbMemberRepository를 넣을지는 동적으로 결정된다.

서버가 실행되고 클라이언트가 실제로 사용하는 인스턴스 객체들을 보기 위한 다이어그램이다.

 

회원 도메인 개발

---

회원 엔티티

• 회원 등급

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

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Grade getGrade() {
        return grade;
    }

    public void setGrade(Grade grade) {
        this.grade = grade;
    }
}

 

회원 저장소

• 회원 저장소 인터페이스

public interface MemberRepository {

    void save(Member member);

    Member findById(Long memberId);
}

• 메모리 회원 저장소 구현체

public class MemoryMemberRepository implements MemberRepository{

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

HashMap은 동시성 이슈가 발생할 수 있으므로 실무에서는 ConcurrentHashMap을 사용한다.

 

회원 서비스

• 회원 서비스 인터페이스

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

• 회원 서비스 구현체

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

구현체가 1개만 있을 때, 관례상 인터페이스명 뒤에 Impl을 붙여서 이름을 짓는다.

 

회원 도메인 실행과 테스트

---

• main 함수를 통한 테스트

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("find member = " + findMember.getName());
    }
}

애플리케이션 로직으로 main 함수에서 테스트 하는 것은 좋은 방법이 아니다. JUnit 테스트를 사용하자.

• JUnit을 이용한 테스트

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

 

회원 도메인 설계의 문제점

추후에 새로운 데이터 저장 방식을 도입할 경우 해당 방식으로 변경해야할 때 클라이언트 코드가 변경되어야 한다. 또한 인터페이스인 MemberRepository 뿐만 아니라 구현체인 MemoryMemberRepository를 모두 의존하고 있다.

⇒ 기능이 확장될 때 기존 코드가 수정되므로 OCP 원칙에 위배되고, 구현체에 의존하므로 DIP 원칙에 위배된다. (OCP, DIP 모두 위배)

 

주문과 할인 도메인 설계

---

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

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

💡 실제로는 주문 데이터를 DB에 저장하지만 여기서는 단순히 주문 결과 객체를 반환하도록 구현한다.

 

주문 도메인 전체

역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있도록 설계했다.

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

 

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

 

도메인 객체 다이어그램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) { // enum 타입은 == 으로 비교
            return discountFixAmount;
        } else {
            return 0;
        }
    }
}

회원의 등급이 VIP일 때 1000원 할인, 아니면 할인 X

💡 enum 타입은 == 으로 비교한다.

 

주문 엔티티

• 주문 엔티티 클래스

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

• Order 객체의 상태를 보기 위해 toString() 재정의한다. (Order 객체를 호출할 때 toString()이 자동 호출된다.)

 

주문 서비스

• 주문 서비스 인터페이스

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

• 주문 생성 요청 → 회원 정보 조회 → 할인 정책 적용 → 주문 객체 생성하여 반환
• 메모리 회원 리포지토리 & 고정 금액 할인 정책을 구현체로 생성

 

주문과 할인 도메인 실행과 테스트

---

• main 함수를 통한 테스트

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

    }
}

애플리케이션 로직으로 main 함수에서 테스트 하는 것은 좋은 방법이 아니다. JUnit 테스트를 사용하자.

• JUnit을 이용한 테스트

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

}

 

주문과 할인 도메인 설계의 문제점

OrderServiceImpl이 가진 문제점도 MemberServiceImpl이 가진 문제와 동일하다.

추후에 새로운 할인 정책이 추가돼서 해당 정책으로 변경해야할 경우 클라이언트 코드가 변경되어야 한다. 또한 인터페이스인 MemberRepository와 DiscountPolicy 뿐만 아니라 구현체인 MemoryMemberRepository, FixDiscountPolicy를 모두 의존하고 있다.

⇒ 기능이 확장될 때 기존 코드가 수정되므로 OCP 원칙에 위배되고, 구현체에 의존하므로 DIP 원칙에 위배된다. (OCP, DIP 모두 위배)