첫째, 비지니스 요구사항 정리
정책적으로 확실한 것과 변경가능성이 높은 지점들도 파악한다.
# 비지니스 요구사항
## 회원
- 회원을 가입하고 조회할 수 있다
- 회원은 일반과 VIP 두 가지 등급이 있다
- 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다.(미확정)
## 주문과 할인 정책
- 회원은 상품을 주문할 수 있다
- 회원 등급에 따라 할인 정책을 적용할 수 있다
- 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용한다. (나중에 변경될 수 있다)
- 할인 정책은 변경 가능성이 높음. 회사의 기본할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 있다. (미확정)
둘째, 개발 설계
요구사항을 반영할 수 있도록 설계한다. 그리고 기능 확장에 용이하도록 OOP를 위한 SOLID 원칙들을 고려하면서 설계한다. *역할과 구현을 구분하여 역할들의 협력 관계를 그대로 재사용할 수 있도록 한다.*
도메인 설계를 통해 개발과 기획이 따로 놀지 않도록 한다. 이 도메인 설계는 개발 외적인 팀이 보고 이해할 수 있을 정도로 개략적으로 표현한다. 비지니스가 잘 담겨서 설계됐다는 것을 서로 체크할 수 있다.
아래는 클래스 다이어그램이다. 개발자를 위한 설계도이다.
아래는 객체 다이어그램이다. 실제 사용하는 객체를 기준으로 작성한다. 그래서 실제 서버가 가동할 때 어떤 객체들, 구현체들이 작동하는지 세밀하고 사실적으로 알아볼 수 있다.
개선점
아래와 같이 클래스를 구현하면 의존성이 2개가 생긴다. MemberRepository의 사용자인 MemberServiceImpl은 역할인 MemberRepository 인터페이스와 구현체인 MemberMemoryRepository 두 개다 참조하고 있다. SOLD 원칙과 OOP 다형성을 위해서라면 사용자인 MemberServiceImpl 에선 구현체를 몰라야 한다.
만약 새로운 정책으로 구현체가 변경되어야 한다면, 클라이언트 객체는 한줄이지만서도 변경점의 영향을 받게 된다. DIP(Dependency inversion principle) 위반이다.
개선
다음과 같이 구현체 참조를 없애서 DIP 원칙을 지키게 했다. 하지만 실행하면 NullPinterException 에러가 발생한다.
그렇다면 클라이언트가 직접 참조하지 않고, 다른 객체가 해주면 원칙을 지킬 수 있다.
의존성 주입
구현 객체를 생성하고 연결의 책임을 설정하는 AppConfig 클래스를 생성하였다. 이제 클라이언트가 기능 사용와 구현체 선택이라는 책임들 중에 구현체 선택을 빼고 기능 구현이라는 것에 집중할 수 있게 되었다.
정리
- 어플리케이션 '사용 영역' 과 '구성 영역'을 명확하게 분리하였다. 자주 변경가능성이 있는 구성영역을 따로 분리하니 사용 영역은 비지니스가 변경되더라도 변화가 없어졌다. 변경 가능성이 큰 부분은 따로 분리한다.
느낀점
- OOP 특징들, SOLID 등 어려운 용어들이 많지만 이 원칙들이 말하고자 하는 바는. 비지니스 요구사항 변경에 유연하게 대응할 수 있는 코드를 작성하는 것이다. 유연하게 설계를 하려면 객체들을 레고처럼 조립하듯 유연하게 설계가 되어야 한다.
'공부노트 > 자바' 카테고리의 다른 글
| JVM 구조 및 메모리 구조 (0) | 2023.09.17 |
|---|---|
| OOP(Object Oriented Programming)와 SOLID 원칙 (0) | 2022.03.19 |
| Java는 Call By Reference가 없다. Object 참조만 있을 뿐. (0) | 2021.11.21 |