의존성 방향
한 줄 정의
의존성 방향은 이미 정한 계층과 모듈 경계를 코드 참조 관계로 지키기 위한 규칙이다.
실무에서 왜 문제 되는가
- 도메인 코드가 웹, DB, 외부 API 타입을 직접 참조하면 테스트와 변경이 어려워진다.
- 공통 모듈이 업무 모듈을 참조하면 순환 의존이 생긴다.
- 편의를 위해 양방향 참조를 허용하면 수정 영향 범위가 커진다.
- 의존성 규칙이 없으면 패키지 구조는 있어도 설계 경계가 무너진다.
실무 판단 기준
| 상황 | 방향 |
|---|---|
| Controller와 Service | Controller가 Service에 의존한다 |
| Service와 Repository | Service가 Repository interface에 의존한다 |
| Domain과 Infrastructure | Domain은 infrastructure 세부사항을 모른다 |
| 공통 모듈과 업무 모듈 | 업무 모듈이 공통 모듈에 의존한다 |
자주 나는 실수
- 도메인 객체에서 HTTP request나 JPA repository를 직접 참조한다.
- util/common 모듈에 업무 로직을 넣는다.
- 순환 의존을 빌드 설정으로 우회한다.
- 인터페이스를 만들었지만 구현 세부사항 이름과 완전히 결합한다.
확인 방법
- 패키지 의존성 그래프에서 순환 의존을 확인한다.
- 핵심 도메인 테스트가 Spring context 없이 가능한지 본다.
- 하위 정책 코드가 상위 입출력 타입을 import하는지 검색한다.
핵심 요약
의존성 방향은 계층과 모듈 경계를 실제 코드에서 유지하기 위한 규칙이다.
핵심 업무 규칙은 웹, DB, 외부 API 세부사항에 직접 의존하지 않는 편이 좋다.
공통 모듈은 업무 모듈을 참조하지 않아야 한다.
순환 의존은 작은 변경도 여러 모듈로 번지게 만든다.
의존성 규칙은 패키지명보다 실제 import 관계로 검증해야 한다.
꼬리 질문
- 도메인이 Repository를 직접 알아도 되는가?
- 순환 의존이 생기면 어떤 문제가 생기는가?
- 인터페이스 분리는 언제 의미가 있는가?