스프링 핵심 원리 이해

비즈니스 요구사항과 설계

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

요구사항을 보면 회원 데이터와 할인 정책 같은 부분은 지금 당장 결정하기 어렵다. 하지만 정책이 결정될 때까지 무작정 기다릴 수도 없다. 인터페이스를 만들어 구현체를 갈아끼울 수 있도록 설계해보자.

클라이언트가 회원 서비스를 호출한다. 회원 서비스는 가입과 조회를 제공한다.

회원 데이터는 자체 DB에 저장할지 외부 시스템과 연동할지 정해지지 않았으므로 메모리, DB, 외부 시스템 중에 선택할 수 있게 한다.

회원 서비스와 리파지토리를 구현하는 클래스를 구현한다.

메모리 간의 참조가 어떻게 되는지 그린 다이어그램이다. 클라이언트는 회원 서비스(정확히는 MemberServiceImpl)를 참조하고, 회원 서비스는 메모리 회원 저장소를 참조한다.

서버가 띄워져야 실제 new 하는 게 뭔지 알 수 있으므로 객체 다이어그램을 따로 그린다. 그래서 클래스 다이어그램은 정적이고, 객체 다이어그램은 동적이다.

실제로는 주문 데이터를 DB에 저장하겠지만, 예제가 너무 복잡해질 수 있어서 생략하고 단순히 주문 결과를 반환하는 방향으로 구현한다.

역할에 구현까지 그린 다이어그램이다. 역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계했다. 따라서 회원 저장소와 할인 정책을 유연하게 변경할 수 있다.

주문처럼 구현 클래스가 하나인 경우엔 impl이라고 관례상 적는다.

클라이언트가 new로 주문 서비스 구현체를 호출하면, 주문 서비스도 new로 저장소와 할인 정책을 선택하게 된다. 역할들의 협력 관계를 그래도 재사용할 수 있는 것이다.

Last updated 4 years ago

Was this helpful?

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