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

비즈니스 요구사항과 설계

• 회원
  • 회원을 가입하고 조회할 수 있다.
  • 회원은 일반과 VIP 두 가지 등급이 있다.
  • 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)

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

• 요구사항을 보면 회원 데이터, 할인 정책 같은 부분은 지금 결정하기 어려운 부분이다. 그렇다고 이런 정책이 결정될 때까지 개발을 무기한 기다릴 수도 없다.
  • 객체 지향 설계 방법을 이용하여 인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계하고 작업을 진행하면 된다.

회원 도메인 설계

• 회원 도메인 요구사항
  • 회원을 가입하고 조회할 수 있다.
  • 회원은 일반과 VIP 두 가지 등급이 있다.
  • 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)

• 회원 도메인 협력 관계
  • 기획자도 볼 수 있는 다이어그램 

    

 

• 회원 클래스 다이어그램
  • 위의 다이어그램을 바탕으로 개발자가 구체화하여 만듬
  • 클래스 다이어그램은 실제 서버를 실행하지 않는 상황(정적)에서 클래스들을 파악하기 쉽다. 

  

 

• 회원 객체 다이어그램
  • 객체 다이어그램은 실제 서버 실행 시, 동적으로 결정되는 구현체들을 파악하기 쉽다.

    

 

회원 도메인 개발

• 회원 등급

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<>(); //동시성 이슈가 있을 수 있으니 ConcurrentHashMap 사용필요
  
      @Override
      public void save(Member member) {
          store.put(member.getId(), member);
      }
  
      @Override
      public Member findById(Long memberId) {
          return store.get(memberId);
      }
  }

• 회원 서비스
  • 회원 서비스 인터페이스

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

 

• 회원 도메인 테스트
  • 회원 도메인 - 회원 가입 테스트

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

 

문제점

• 기존의 저장소를 다른 저장소로 변경할 때 OCP, DIP 원칙을 위배한다.
  • 의존관계가 인터페이스 뿐만 아니라 구현까지 모두 의존하고 있기 때문이다.

---

[참고자료]

스프링 핵심 원리 - 기본편, 김영한