Cycle 끊기
- 중간 객체를 이용해 의존성 cycle 제거
- DIP: 클래스를 구체적인 것에 의존하지 않고, 추상적인 것에 의존하도록 만들기
- 추상적인 것 == 잘 안 변하는 것
- 객체 참조를 끊어버리기
- 객체 참조의 문제점: 어디까지 조회할 것인가? Lazy Loading을 고려해야함
- 트랜잭션의 범위는 어디까지?
객체 참조가 꼭 필요하세요?
- 본질적으로 결합도가 높은 친구들은 묶어야 함 (참조로 접근)
- @Transaction: 다 같이 변경되어야 하는 것
- tuning의 경계를 잡아줌
- eager로 끌고 올래? lazy로 끌고 올래?
- 그룹 단위의 영속성 저장소 변경 가능
- 나머지는 Id를 기반으로 Repository를 통한 탐색 (Id로 접근)
- 연관관계를 구현하는 연산을 절차지향적으로 보여주기 좋음
- 비즈니스 로직 처리엔 용이하지만, 조회 로직이 섞이면 양방향으로 지지고 볶고 하긴 해야함...
근데 객체 참조를 Id 참조로 바꾸면 컴파일 에러 나잖아요?
- [Case 1] 객체 직접참조 로직을 다른 객체로 옮김
- ex. Validation의 경우, 필요한 Validation 로직을 절차지향적으로 작성해 빈으로 등록하고 이를 활용
- [Case 2] 도메인의 순차적 로직 실행되는 경우
- ex. Order.delivered(), Deliver.done() 을 둘 다 해줘야하는 경우
- [Sol 1] 앞에 처럼 절차 지향 로직으로 쇼부보기
- OrderDeliverService를 만들어 절차지향적으로 로직 써주기
- 근데 이러면 패키지 의존 사이클 발생 가능성있음
- DIP를 적용하자!
- Interface는 Order에 두고, 실 구현체는 Deliver에 두기
- [Sol 2] Domain Event Publish
- Order가 Shop을 직접 호출하던 로직을, Order가 Domain Event 발행토록 수정
- Event Publish: DB Commit 후 발행
- Shop에 ShopEventHandler를 넣어두면 cycle 또 발생할 수 있음
- 이러면 패키지로 따로 분리하자
패키지 의존성 제거 방법
1. 중간 객체 만들어 변환
2. 인터페이스/추상클래스의 DIP
3. 새로운 패키지로 찢기
도메인 단위 모듈 == 시스템 분리의 기반
- System 분리가 쉬워진다!
- Event 발행을 시스템 단위로!
- MSA + System Event => 의존성에 따른 진화!