김영한 스프링 핵심 원리 기본 편 복습 - 1

순수 자바 프로젝트로 도메인 설계와 구현

1. 시작

김영한 스프링 핵심 원리 기본 편을 바탕으로 하였음을 밝힙니다.

이번 프로젝트에서는 순수한 자바로만 회원, 주문, 할인 도메인을 설계하고 구현할 예정입니다. 역할과 구현을 명확히 분리하여 인터페이스와 구현 객체를 나누어 개발하며, 객체 지향 설계의 핵심 원칙(OCP, DIP)이 잘 지켜지는지 또한 검증해볼 것입니다. 또한, 비즈니스 요구사항 변경에 유연하게 대응 가능한 설계를 목표로 합니다.

start.spring.io 사이트를 통해서 빠르게 스프링 프로젝트를 구상합니다.
단순히 프로젝트 환경설정의 편리함을 위해서 스프링 부트를 사용한 것이고, 스프링 없이 순수한 자바로만 개발할 것이다.

프로젝트를 인텔리제이로 열었으면 한번 run을 해봅니다.
스프링 웹 프로젝트를 넣지 않았으니 즉시 application이 꺼지는 것이 맞다.

회원 도메인

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

주문, 할인 도메인
회원은 상품을 주문할 수 있음
회원 등급에 따라 할인 정책을 적용할 수 있음
할인 정책 : 모든 VIP는 1000원을 할인
할인 정책은 변할 수 있다. 오픈 직전에도 변할 수 있다.
(하지만 우리는 괜찮다. 역할과 구현을 구분하면 되기 때문이다)

회원 도메인 협력 관계와 같은 그림은 기획자도 볼 수 있는 것이다.

하지만 클래스 다이어그램은 실제 서버를 실행하지 않고 클래스만 분석해서 볼 수 있는 그림이다.
구현체들 같은 경우는 동적으로 결정될 때가 많다. 서버가 뜰 때 결정될 때가 많다.

그래서 객체 다이어그램이라는게 따로 있다.
실제로 서버가 떠서 클라이언트에게 제공되는 인스턴스에 대한 것이다.
즉, 객체 다이어그램은 정적이고, 클래스 다이어그램은 동적이다.

 

2. 회원 도메인

그렇게 코드 구현을 마쳤다.

잘 구현되었는지 보기 위해 memberService를 보자

과연 잘 구현되었는가? 기능은 잘 돌아간다.
하지만 MemberService는 현재 MemberRepository의 추상화에만 의존하는 것이 아니라
구체화에도 의존하는 상황이다. 즉, 이것은 DIP를 위반하고 있는 것이다.

3. 주문 도메인

주문의 과정은 어떻게 이루어질까?
먼저 클라이언트가 주문을 할 것이다.
그러면 결론적으로 먼저 말하면 주문 서비스는 주문 결과를 반환해줄 것이다.
주문 서비스는 어떻게 주문 결과를 만들까?
먼저 이 회원이 VIP인지 BASIC인지 확인을 해야 할 것이다.
(그래야 1000원을 깎을지 말지 결정할 것이기 때문이다)
그 다음으로 VIP라면 할인을 적용해야 하므로 할인 정책에게 물어본다.
할인 정책은 주문 서비스와 따로 관리해주면 좋을 것이다.
그리고 할인 정책은 추상체(역할)와 구현체(구현)을 분리하는 게 좋을 것이다.
그래야 할인 정책이 변경되었을 때 갈아 끼우기 좋을 것이기 때문이다.

참고 : 실제로는 주문 데이터를 DB에 저장을 하겠지만 예제의 단순화를 위해서 그 과정은 생략하고, 주문 결과만 반환하는 것으로 하겠다.

다음은 클래스 다이어그램, 객체 다이어그램이다.

 

 

기능과 역할을 분리했을 때의 장점은 무엇이냐.
회원저장소가 메모리 회원저장소에서 DB회원 저장소로 구현체가 바뀌었다.
할인 정책이 정액 할인 정책에서 정률 할인 정책으로 바뀌었다.
그렇다고 하더라도 주문 서비스 구현체는 전혀 바뀔 필요가 없다는 아름다운 상황을 볼 수 있다.
즉, 역할들의 협력관계를 그대로 재사용 할 수 있다.

4. 좋은 단축키

F2를 누르면 에러가 난 부분으로 즉시 이동한다.

ctrl shift enter는 불완전한 코드 문법을 완성해준다.

ctrl alt v 는 데이터를 변수에 할당해주고, 동시에 변수명을 추천해준다. introduce variable 기능이라고 한다. 예를 들어 new Member(데이터)를 하고 사용하면 변수에 할당해준다.

5. 학습하고 난 후

기능과 역할을 분리했을 때의 장점이 무엇일까?
역할들의 협력관계를 그대로 재사용할 수 있다.
각 역할들이 잘 설계되었는 지 어떻게 판단할까?
그 역할이 바뀌었을 때 다른 역할들은 전혀 바꿀 필요가 없다면 잘 설계한 것이다.
즉, 단일책임의 원칙을 잘 지켰는지를 확인하면 된다.