설계에 대한 핵심은 의존성이다.
역할과 책임이 필요한 건 의존성을 어떻게 관리하느냐가 핵심이다.
어떻게 의존성을 관리하는 것이 좋은 의존성이고 의존성을 관리하는 방법에 대해서 설계가 어떻게 달라지는지 살펴보자.
의존성이라는 것은 변경에 의한 영향을 받을 수 있는 가능성이라고 생각하면 쉽다.
1) 클래스 의존성의 종류
- 연관관계: 협력을 위해 필요한 영구적인 탐색구조
- 의존관계: 협력을 위해 일시적으로 필요한 의존성(파라미터, 리턴타입, 지연변수)
- 상속관계
- 실체화 관계
2) 패키지 의존성의 종류: 패키지에 포함된 클래스 사이의 의존성
좋은 의존성을 관리하기 위한 방법
1) 양방향 의존성을 피하라
2) 다중성이 적은 방향을 선택하라
-> 즉 One-To-Many 보단 Many-To-One
3) 의존성이 필요없다면 제거하라
4) 패키지 사이의 의존성 사이클을 제거하라
주문 플로우
가게 선택 -> 메뉴 선택 -> 장바구니 담기 -> 주문완료
1) 예외 상황 / 주문 Validation
주문을 장바구니에 담았을 때 가게 사장이 담았던 메뉴를 수정하면 가게에서 팔지 않는 주문을 하게될 수 있다.
그렇기에 발생한 주문을 사장님에게 알리기 전에 다음과 같은 유효성 체크를 해야한다.
1) 메뉴의 이름과 주문항목의 이름 비교 - 3순위
2) 옵션 그룹의 이름과 주문옵션그룹의 이름 비교 - 4순위
3) 옵션의 이름과 주문옵션의 이름 비교 - 5순위
4) 옵션의 가격과 주문옵션의 가격 비교 - 6순위
5) 가게가 영업중인지 확인 - 1순위
6) 주문금액이 최소주문금액 이상인지 - 2순위
다음을 살펴보았을 때 양방향 연관관계가 생겨있다.
이를 해결하기 위해 다음과 같이 해결하였다.
중간 객체를 이용한 의존성 사이클 끊기
객체 참조로 구현한 연관관계의 문제점
협력을 위해 필요하지만 두 객체 사이의 결합도가 높아짐
성능문제 - 객체들이 다 연결되어있기 때문에 어떤 객체이든 탐색이 가능해짐으로써 조회 경계가 모호해진다.
수정 시 도메인 규칙을 함께 적용할 경계는?
Order의 상태를 변경할 때 연관된 도메인 규칙을 함께 적용해야하는 객체의 범위는? -> 트랜잭션 경계는 어디까지인가? 어떤 테이블에서 어떤 테이블까지 하나의 단위로 잠금을 설정할 것인가?
변경의 빈도가 다르기 때문에 객체를 좇다보면 트랜잭션 경합으로 인한 성능 저하가 발생한다.
객체 참조가 꼭 필요할까?
객체참조는 결합도가 가장 높은 의존성
귀요미 개발자