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

[cyzlcyzl]

프로젝트 생성

Intellij Ultimate 버전을 사용하면 IDE에서 스프링부트 프로젝트를 바로 생성하고 실행할 수 있어 IDE를 활용한다.
스프링부트 프로젝트를 생성하지만 현 예제에서는 순수 자바 코드로만 진행할 것이기 때문에 Dependencies 는 패스

비즈니스 요구사항과 설계

• 회원

  • 가입 및 조회
  • 등급 존재 (일반/VIP)
  • 자체 DB를 구축할 수도 있고, 외부 시스템과 연동할 수도 있다. (미확정)

• 주문과 할인 정책

  • 회원은 상품을 주문할 수 있다.
  • 등급에 따른 할인 정책
  • 할인정책: 모든 VIP는 1000원 할인 (정액 할인) - 나중에 변경될 수도 있음
  • 기본 할인 정책은 아직 미확정. 오픈 직전까지 고민을 미루고 싶고 최악의 경우 적용하지 않을 수도 있음

회원 DB와 할인 정책처럼 미확정인 요구사항이 존재한다.
→ 인터페이스를 만들고 구현체만 언제든지 바꿀 수 있도록 설계

회원 도메인 설계

- 회원 도메인 협력 관계

클라이언트는 회원 서비스를 의존하고 회원 서비스는 회원 저장소를 의존한다. 회원 저장소는 아직 미확정이기 때문에 인터페이스를 설계하고 메모리/DB/외부시스템 연동으로 구현될 수 있다.

- 회원 클래스 다이어그램

MemberService 인터페이스를 MemberServiceImpl이 구현하고 이는 MemberRepository를 의존한다. MemberRepository는 인터페이스로 현 예제에서는 MemberMemoryRepository로 구현된다.

- 회원 객체 다이어그램

클라이언트가 바라보는 회원 서비스는 MemberServiceImpl인 구현체이며 MemberServiceImpl 역시 구현체인 MemoryMemberService를 바라본다.

인터페이스와 구현 클래스로 나누어 역할과 구현을 구분해주었다.

회원 도메인 개발

• 회원 엔티티
  • 회원 등급 (Grade)
    • BASIC, VIP
  • 회원 (Member)
    • id, name, grade
• 회원 저장소
  • 인터페이스 MemberRepository
  • 구현체 MemoryMemberRepository

      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을 활용해서 메모리 저장소를 구현한다.
• 회원 서비스
  • 인터페이스 MemberService
  • 구현체 MemberServiceImpl

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

회원 도메인 실행과 테스트

① main 메서드를 활용

콘솔창을 통해 결과를 확인할 수 있지만 직접 비교해야 한다는 단점이 있으며 정확하지 않을 수 있다.

② JUnit 테스트 활용

given-when-then 패턴 활용

❓회원 도메인 설계의 문제점

MemberServiceImpl(클라이언트)에서 MemberRepository의 구현체인 MemoryMemberRepository를 직접 호출하고 있다.
: OCP 위반 - 추후 저장소에 관한 구현체를 변경할 때 클라이언트 코드를 직접 변경해야 한다.
: DIP 위반 - 인터페이스가 아닌 구현 클래스에 의존하고 있다.

주문과 할인 도메인 설계

주문 도메인 전체

클라이언트가 주문 서비스에 주문 생성을 요청하면 ➡️ 회원을 조회해서 회원의 등급을 확인하고➡️ 회원 등급에 따라 할인 여부를 할인 정책에 위임한다 ➡️ 주문 서비스는 할인 결과를 포함한 주문 결과를 반환한다.

회원 저장소(인터페이스)는 메모리 회원 저장소(구현)가 될 수도, DB 회원 저장소(구현)가 될 수도 있다.
할인 정책(인터페이스)은 정액 할인 정책(구현)이 될 수도 정률 할인 정책(구현)이 될 수도 있다.
인터페이스와 구현 클래스를 나누어 역할과 구현을 분리해 불확실한 요구사항에도 유연하게 변경할 수 있다.

주문과 할인 도메인 개발

• 할인 정책 인터페이스 (DiscountPolicy)
  • 정액 할인 정책 구현체 (FixedDiscountPolicy)

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

    회원 등급이 VIP면 1000원 할인 적용 / BASIC인 경우에는 해당 없음
• 주문 엔티티 (Order)
  • memberId, itemName, itemPrice, discountPrice
• 주문 서비스
  • 인터페이스 OrderService
  • 구현체 OrderServiceImpl

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

    할인 정책과 주문을 분리하여 최소한의 역할만 가져야 한다는 SRP (단일 책임의 원칙)을 잘 준수하고 있음을 알 수 있다.
    주문 생성 요청이 들어오면 ➡️ 회원 조회를 하고 ➡️ 회원에 따른 할인을 계산하고 ➡️ 주문 객체를 반환한다.

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

① main 메서드를 활용

콘솔창을 통해 결과를 확인할 수 있지만 역시 JUnit 테스트를 활용하는 것을 지향해야 한다.

② JUnit 테스트 활용

given-when-then 패턴 활용

---

현 예제까지는 인터페이스와 구현 클래스를 분리하여 역할과 구현을 분리했지만, 결국 클라이언트에서 구현체를 알고 있기 때문에 OCP와 DIP가 잘 지켜지지 않고 있다. 이러한 문제점은 다음 시간에 고쳐 나갈 예정!

[6om1n]

수고하셨습니다 ~!