비지니스 요구사항
서비스를 개발하기 전, 어떤 기능이 있는지 정리를 해둬야 개발할 수 있다.
그래서 맨 처음 요구사항들을 정리한다.
회원
- 회원은 가입하고 조회할 수 있음
- 회원은 일반과 vip 두가지 등급이 있다.
- 회원 데이터는 자체 db를 구축할 수 있고, 외부 시스템과 연동할 수 있다.(미확정)주문과 할인 정책
- 회원은 상품을 주문할 수 있다.
- 회원 등급에 따라 할인 정책을 적용할 수 있다.
- 학인 정책은 모든 vip는 천원씩 할인해주는 고정금액 할인, 나중에 변경 가능
- 할인 정책은 변경 가능성이 높다.
- 최악의 경우 적용하지 않을 수 있다.
요구사항을 보면 회원데이터, 할인 정책 같은 부분은 지금 결정하기 어려운 부분이다. 그렇다고 이런 정책이 결정될 때 까지 개발을 기다릴 수는 없다.
인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계하면 된다 ~~
현재는 스피링 프레임 워크는 적용되어있지 않다.
회원 도메인 설계
- 회원을 가입하고 조회할 수 있다.
- 회원은 일반과 vip 두가지 등급이 있다.
- 회원 데이터는 자체 DB를 구축할 수 있고, 외부시스템과도 연동할 수 있다. 회원 도메인 협력 관계
기획자들도 볼 수 있는 관계이다. 이것을 바탕으로 개발자가 클래스 다이어그램을 만든다.
클라이언트가 회원 서비스로 가고
회원 서비스는 회원 가입, 회원 조회 두가지 기능 가능
회원 저장소라는 인터페이스 만듦 (외부 데이터랑 연동할 수도 있으니까)
그리고 구현체를 세개 만든다.
- 메모리 회원 저장소,
- 디비 회원 저장소,
- 외부 시스템 연동 회원 저장소를 만들어
위에 세가지 중 무엇으로 할 지 정해지지 않았으니 제일 간단하게 메모리 회원 저장소를 이용하겠다. 그런데 메모리 회원 저장소는 컴퓨터를 껐다가 키면 다 사라진다.
즉 역할과 구현을 나눈 방법이다.
회원 클래스 다이어그램
인터페이스와 구현체에 대해서 적어둔다.
실제 서버를 실행하지 않고, 클래스만 분석할 수 있는 것들이다.
memberService 라는 역할을 만들고, 구현 클래스로 memberServiceimpl 를 만든다.
memberRepository 라는 역할을 만들고, 구현 클래스로 memoryMemberRepository,
DbmemberRepository 를 만든다.
위에 대로 코딩하면 된다. 그런데 구현체(memoryMemberRepository,DbmemberRepository)
같은 경우는 new 해서 서버가 뜰 때 결정되기 때문에 클래스 다이어그램만으로
판단하기가 어렵다 그래서 객체 다이어그램을 만든다.
회원 객체 다이어그램
클라이언트가 실제 인스턴스끼리의 참조를 적어둔다.
- 회원 서비스 : MemberServiceImpl
객체 간에 메모리 참조가되는 과정이다.
회원 도메인 설계의 문제점
이 코드의 설계상 문제점이 무엇일까?
다른 저장소로 변경할 때 ocp 원칙을 잘 준수할까?
dip를 잘 지키고 있을까
의존 관계가 인터페이스 뿐만 아니라 구현까지 모두 의존하는 문제점이 있다.
주문까지 만들고 나서 문제점과 해결 방안을 설명하겠다.
주문과 할인 도메인 설계
주문을 생성 : 클라이언트는 주문 서비스에 주문 생성을 요청한다.
회원 조회 : 할인을 위해서는 회원 등급이 필요하다. 그래서 주문 서비스는 회원 저장소에서 회원을 조회
할인 적용 : 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임한다.
주문 결과 반환 : 주문 서비스는 할인 결괄르 포함한 주문 결과를 반환한다.
실제로는 주문 데이터를 디비에 저장하겠지만, 예제가 너무 복잡해질 수 있어서 생략하고 단순히 주문 결과를 반환!
주문 도메인 클래스 다이어그램
주문 도메인 객체 다이어그램1
주문 도메인 객체 다이어그램2
]
새로운 할인 정책 개발
갑자기 기획자가 와서 말한다.
고정 할인을 정률 할인으로 정책을 바꿔보자. 고정된 금액(예 1000원) 이 아닌,
주문 금액에서 10%를 할인해주는 겁니다 ~~
처음부터 고정 할인으로 가면 좋았을 걸.. 그래도 기획자가
애자일 소프트웨어 개발 선언
