Dependency
- 어떻게 의존성을 관리하느냐. 의존성에 따라서 설계가 어떻게 바뀌는지를 통해 의존성을 어떻게 관리하는지
- 변경에 의한 영향을 받느냐
- 클래스 사이의 Dependency
- Association (연관관계) A가 B를 아예 필드로 갖는 것
- Dependency(의존 관계) 메서드나 파라미터로 잠시 나오는 것
- Inheritance (상속 관계) - 구현 바뀌는 것에 영향
- Realization(실체화 관계) - 시그니처 바뀌는 것에 영향
- 패키지 사이의 Dependency
- 패키지 B에 있는 클래스가 다른 패키지 안에 있는 클래스에 의존성이(위의 4가지 중 아무거나) 있으면 의존성이 있다라고 함
지시
- 양방향 의존성을 피하라
- 굉장히 신경쓸 것이 많음
- 성능 상 이슈도 있음
- 다중성이 적은 방향을 선택하라
- OneToMany보다 ManyToOne쪽이 더 나음
- A가 B의 list를 가지는 것보다 B가 A 하나를 가지는게 좋음
- 의존성이 필요없다면 제거하라
- 패키지 사이의 의존성 사이클을 제거하라(양방향 x, 단방향으로)
레이어 아키텍처 중 Domain 부분
- db는 방향성이 없지만, 객체는 방향성이 있음. 방향성 결정하는게 굉장히 중요하다
- 관계의 방향 = 협력의 방향 = 의존성의 방향
연관관계
- 객체 협력을 위해 필요한 영구적인 탐색 구조
- 빈번하게 참조를 한다면 연관관계로 잡기
- Order에서 OrderLineItem으로 탐색가능(연관관계 = 탐색가능성 navigability)
- 구현 방법
- 가장 대표적인 방법 중 하나 : 객체 참조
- 의존관계 : 협력을 위해 일시적으로 필요한 의존성
- (파라미터, 리턴타입, 지연변수)
- 이 둘 중 어떤것을 선택하느냐가 중요하기 보다는 방향성이 중요함
- 코드를 짜고나서 dependency를 다 그려보기
- 설계를 어떻게 개선해야 할지에 대해 그림이 보이게 됨
두 가지 문제
객체 참조로 인한 결합도 상승
객체 참조로 구현한 연관관계의 문제점
- 협력을 위해 필요하지만 두 객체 사이의 결합이 강해짐. 결합도가 가장 높은 의존성임 ⇒ 필요한 경우에는 객체 참조 끊기
- 객체 참조를 다 하고 있으니 트랜잭션 경계를 어디까지 할꺼냐
- 비즈니스 로직이 추가될수록 상태를 바꿔줘야 할 객체들이 더 추가되고 transaction이 점점 더 길어지게 됨
- 트랜잭션으로 묶이는 3개의 도메인의 변경빈도가 달라지고
- 트랜잭션 경합으로 인해 성능이 저하됨
Repository를 통한 탐색(약한 결합도)
public class Order { @Column(name="SHOP_ID") private Long shopId; } Shop shop = shopRepository.findById(order.getShopId());
- 비즈니스 로직은 단방향이 조금 쉬운데
- 조회 로직은 양방향이 막 들어가게 됨
어떤 객체들을 묶고 어떤 객체들을 분리할 것인가? (aggregate 묶는 방법)
- 함께 생성되고 함께 삭제되는 객체들을 함께 묶어라 → 그렇지 않다면 끊어버려라
- 도메인 제약사항을 공유하는 객체들을 함께 묶어라
- 얘가 바뀔 때 굳이 얘가 안 바뀌어도 돼 면 끊기
- 가능하면 분리하라
- 비즈니스 룰에 따라 분리가 결정이 됨
- 경계 안의 객체는 참조를 이용해 접근
- aggregate 그룹 사이에는 id로 참조하기
- 경계 끼리는 같이 읽고 다른 경계면 다른 Transaction으로
- 그룹은 트랜잭션/조회/비즈니스 제약의 단위 (하나의 단위로 저장)