설계는 변경과 관련이 있다.
의존성 : 클래스 의존성, 패키지 의존성(패키지에 포함된 클래스 사이의 의존성)
A -> B : A가 B에 의존한다. B가 변경되면 A에 영향이 있다.
가이드
- 양방향 의존성을 피하라
- 다중성이 적은 방향을 피하라 : 1:N 검색, 삭제 등 비용이 커진다.
- 패키지 사이의 의존성 사이클을 제거하라 *** (싸이클 제거)
리파지토리 구현 클래스를 인프라스트럭쳐 영역에 위치시켜서 인프라스트럭쳐에 대한 의존을 낮춰야한다.
인프라스트럭쳐는 표현, 응용, 도메인 영역을 지원한다.
도메인 객체의 영속성 처리, 트랙잭션, Rest Client 등 다른 영역에서 필요하는 하는 구현 기술, 보조기능을 지원한다.
객체와 디비는 다르다. 객체는 행동, 디비는 중복 제거를 한다.
이걸 해결하기 위해 JPA를 사용하지만 Lazy loading이 문제가 된다. 어디까지 읽어야 할까?
그러다 보면 조회하고, 비즈니스 처리하고, 널 체크하고 이런 식으로 로직이 만들어진다.
그리고 성능문제가 발생한다. 객체 그룹 조회 경계 모호해지며 트랜잭션 경계는 어디까지인가?
객체 참조가 꼭 필요할까?
객체참조는 결합도가 가장 높은 의존성이다. 객체 참조를 끊자
- 함께 생성되고 함께 삭제되는 객체들을 함께 묶어라
- 도메인 제약사항을 공유하는 객체들을 함께 묶어라.
댓글
댓글 쓰기