예제를 통해 스프링의 핵심 원리 이해하기(1)
비즈니스 요구사항과 설계
회원
- 회원 가입 및 조회
- 일반 등급, VIP 등급
- 회원 데이터 -> 자체 DB를 구축 or 외부 시스템과 연동(미확정)
주문과 할인 정책
- 회원은 상품 주문 가능
- 회원 등급에 따라 할인 정책 적용 가능
- 할인 정책: 모든 VIP는 1,000원 할인(고정 금액 할인)
- 할인 정책은 미확정(적용 안 할 가능성도 존재)
회원 도메인 설계
- 회원 데이터를 저장할 DB가 확정되지 않았음
-> 개발용 '메모리 회원 저장소' 구현
-> 추후 확정되면 자체DB or 외부 시스템을 구현하여 교체
회원서비스: MemberServiceImpl
애플리케이션 로직으로 테스트하는 것은 좋은 방법이 아님
-> JUnit 테스트 이용
테스트 실패 시 출력 결과 없이 오류 여부를 알려줌
- 테스트는 선택이 아닌 필수
| 테스트 성공
회원 도메인 설계의 문제점
- 의존 관계가 인터페이스, 구현 모두 의존
-> DIP 위반
주문과 할인 도메인 설계
- 주문 생성: 클라이언트는 주문 서비스에 주문 생성 요청
- 회원 조회: 회원 등급에 따른 할인 필요. 주문 서비스는 회원 저장소에서 회원 조회
- 할인 적용: 회원 등급에 따른 할인 여부를 할인 정책에 위임
- 주문 결과 반환: 주문 서비스는 할인 결과를 포함한 주문 결과 반환
- 실제로는 주문 데이터를 DB에 저장하지만, 예제의 간편성을 위해 생략
주문 도메인 전체
역할과 구현을 분리하여 자유롭게 조립할 수 있도록 설계
회원 저장소: 메모리에 저장/DB에 저장
할인 정책: 정액 할인/정률 할인
▸ 정액 할인 정책: 고정 금액 할인
▸ 정률 할인 정책: 비율 할인
주문 도메인 객체 다이어그램 1
- 회원을 메모리에서 조회
- 정액 할인 정책 적용
주문 도메인 객체 다이어그램 2
- 회원을 DB에서 조회
- 정률 할인 정책 적용
데이터 저장, 할인 정책이 변경되어도 객체들을 조립하여 사용할 수 있도록 설계
| 테스트 성공
*정률 할인 정책으로 깔끔하게 바꿀 수 있는가?
-> 다음 강의 예제를 통해 확인
고민중