프로젝트 설계
객체 지향의 프로젝트를 회원, 주문과 할인 정책을 예로 들어 정리한다.
비즈니스 요구사항
•
회원
◦
회원을 가입하고 조회할 수 있다.
◦
회원은 일반과 VIP 두 가지 등급이 있다.
◦
회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)
•
주문과 할인 정책
◦
회원은 상품을 주문할 수 있다.
◦
회원 등급에 따라 할인 정책을 적용할 수 있다.
◦
할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수
있다.)
◦
할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을
미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정)
회원
0. 회원 도메인 요구사항
•
회원을 가입하고 조회할 수 있다.
•
회원은 일반과 VIP 두 가지 등급이 있다.
•
회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)
미확정된 부분은 우리가 객체지향 설계를 함으로써 추후에 확정되었을 때 쉽게 적용할 수 있다.
1. 회원 도메인 협력 관계
•
개발팀 뿐 아니라 기획팀 모두가 이해할 수 있도록 큰 틀을 잡는 단계
•
이를 가지고 구체화하여 개발자들이 클래스 다이어그램을 만들어냄
2. 회원 클래스 다이어그램(구현 레밸)
•
도메인을 보고 개발을 위해 구체화하는 단계
•
인터페이스(역할)
◦
회원 서비스 - MemeberService
◦
회원 저장소 - Member Repository
•
Class(구현)
◦
회원 서비스의 구현체 - MemberServiceImpl
◦
회원 저장소의 구현체 - Member/DB MemberRepository
3. 회원 객체 다이어그램
•
객체간 참조 다이어그램
•
실제 서버가 올라갔을 때를 생각하면, 회원서비스는 MemberServiceImpl을 의미하고 회원 저장소는 현재 Memory로 구현했다고 생각하면 MemoryMemberRepositry가 된다.
클래스 다이어그램에서 구현체들(MemberServiceImpl, MemoryMemberRepository, DBMemoryMemberRepository)중 어떠한 것이 쓰이는지는 동적으로 결졍된다.
→ 서버가 실행될 때 new [구현체명]() 을 사용해 결정하기 때문에 클래스 다이어그램만으로 판단하기 힘들다. 그렇기에 서버가 실해될 때 실제 사용되는 구현체를 지정하는 다이어그램이라 생각하면 된다.
주문과 할인
0. 주문과 할인 정책(요구사항)
•
회원은 상품을 주문할 수 있다.
•
회원 등급에 따라 할인 정책을 적용할 수 있다.
•
할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수
있다.)
•
할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을
미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정)
1. 주문 도메인 (협력, 역할, 책임)
1.
주문생성 : 클라이언트는 주문 서비스에 주문을 요청
2.
회원조회 : 할인을 위해서는 회원 등급이 필요, 그래서 서비스는 회원 저장소에서 회원 조회
3.
할인 적용 : 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임
4.
주문 결과 반환 : 주문 서비스는 할인 결과를 포함한 주문 결과를 반환
역할까지만 구현한 상태 == 인터페이스만 그린 상태
역할 + 구현체까지 그린 상태 == 주문 도메인 전체
2. 주문 클래스 다이어그램(구현 레밸)
•
•
인터페이스(역할)
◦
주문 서비스 역할 - OrderService
◦
회원 저장소 역할 - Member Repository
◦
할인 정책 역할 - DisCountPolicy
•
Class(구현)
◦
주문 서비스 구현체 - OrderServiceImpl
◦
회원 저장소 구현체 - MemoryMemberRepository, DBMemberRepository
◦
할인 정책 구현체 - FixDisCountPolicy, RateDisCountPolicy