[spirng]비즈니스 요구사항

김영한 강사님 강의를 수강하며 정리한 내용 입니다.

비즈니스 요구사항과 설계

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

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

도메인 --> 1. 회원 2. 주문 3. 할인정책

인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계해야 한다. 일단은 스프링 없이 순수한 자바로만 개발을 진행해보자.

회원 도메인 설계

"클라이언트"가 "회원서비스"를 호출한다. 그 후 "회원 저장소"(인터페이스)를 따로 만든다. 회원 데이터에 접근하는 계층을 따로 만들고 "회원 저장소"의 구현을 "메모리 저장소", "DB 회원 저장소", "외부 시스템 연동 회원 저장소"로 만든다.

클래스 다이어그램은 정적 다이어그램이다.

객체 다이어그램은 동적 다이어그램이다. "클라이언트"는 MemberServiceImpl을 사용하게 되고 "회원 서비스"는 "메모리 회원 저장소"를 참조한다.

회원 도메인 설계의 문제점

• 의존관계가 인터페이스 뿐만 아니라 구현까지 모두 의존하는 문제점이 있다.
  -> MemberServiceImpl이 MemoryMemberRepository까지 의존하고 있다.

주문과 할인 도메인 설계

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

역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있다. 덕분에 회원 저장소는 물론이고, 할인 정책도 유연하게 변경할 수 있다.


회원을 메모리에서 조회하고, 정액 할인 정책(FixDiscountPolicy)를 지원해도 주문 서비스를 변경하지 않아도 된다.