Spring 의존 역전 원칙 (Dependency Inversion Principle)이란?

 

 

 

 

DIP의 본질

1. DIP 원칙이란 객체에서 어떤 Class를 참조해서 사용해야하는 상황이 생긴다면, 그 Class를 직접 참조하는 것이 아니라 그 대상의 상위 요소(추상 클래스 or 인터페이스)로 참조하라는 원칙이다.
2. DIP를 단순히 "인터페이스를 쓰면 된다"로 이해하면 실무에서 패키지 구조를 잘못 설계하게 된다.
   DDD의 레이어 아키텍처와 함께 의존성의 방향을 제어하는 원칙으로 이해해야 한다.
3. 즉, 고차원 모듈(비즈니스 로직)이 저차원 모듈(구현 세부사항)에 의존하면 안된다는 것이다.
   1. 인터페이스의 소유권이 중요하다. 인터페이스는 "사용하는 쪽"이 소유한다
   2. 의존성 방향은 항상 안쪽(도메인)을 향한다
   3. 구현체가 바뀌어도 비즈니스 로직은 영향받지 않는다
4. 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 것이 의존 역전 원칙이다.

 

 

“고차원 모듈은 저차원 모듈에 의존하면 안 된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.”
로버트 C. 마틴

1. 고차원 모듈
   일반적으로 더 큰 규모의 기능을 수행하는 클래스, 패키지 등을 의미한다.
   즉, 사용자 인터페이스와 관련된 작업을 하는 Controller나 비즈니스 로직을 처리하는 Service 계층이 고차원 모듈에 속한다.
2. 저차원 모듈
   고차원 모듈에서 정의한 기능을 구체적으로 구현하는 클래스 등을 의미한다.
   주로 데이터베이스 접근 객체(DAO) 클래스나 파일 처리를 위한 클래스 등이 저차원 모듈에 속한다.

 

 

 

 

실무 예시: 주문 시스템

시나리오

주문 결제 모듈을 현재는 토스페이먼츠를 쓰지만, 향후 카카오페이, 네이버페이로 교체될 수 있다.

 

DIP 위반 구조

문제: 인터페이스가 infrastructure에 있으면, domain이 infrastructure를 import해야 함을 가정

com.example.shop
├── domain
│   └── order
│       └── OrderService.java      // 도메인 서비스
├── infrastructure
│   └── payment
│       ├── PaymentGateway.java    // 인터페이스 ← 문제!
│       └── TossPaymentGateway.java
...  


// OrderService.java
// → 고수준(domain)이 저수준(infrastructure)에 의존
import com.example.shop.infrastructure.payment.PaymentGateway; // ❌ 위반!

 

 

DIP 준수 구조

com.example.shop
├── domain
│   └── order
│       ├── Order.java                    // 엔티티
│       ├── OrderService.java             // 도메인 서비스
│       └── PaymentProcessor.java         // 인터페이스 ← 도메인이 소유해야함!
│
├── infrastructure
│   └── payment
│       └── TossPaymentProcessor.java     // 구현체
│
└── application
    └── order
        └── OrderFacade.java              // 조립(DI 설정)

 

 

 

 

 

 

 

 

 

 

 

 

DIP가 DDD에서 작동하는 방식

아키텍처 레벨로 이해하기

┌────────────────────────────────────────┐
│           Presentation                 │  ← Controller, DTO
├────────────────────────────────────────┤
│           Application                  │  ← UseCase, Facade
├────────────────────────────────────────┤
│             Domain                     │  ← Entity, Value Object, Domain Service
│                                        │     Repository Interface ← 여기 정의!
├────────────────────────────────────────┤
│          Infrastructure                │  ← Repository 구현, 외부 API 연동
└────────────────────────────────────────┘
의존 방향: 바깥 → 안쪽 (한 방향만 허용)​

 

 

 

의존 방향으로 이해하기

Infrastructure가 Domain을 의존하며, Domain은 Infrastructure 몰라도 된다.

 

               의존 방향 (컴파일 타임)
─────────────────────────────────▶
┌────────────┐   ┌────────────┐   ┌────────────┐   ┌──────────────┐
│Presentation│──▶│Application │──▶│   Domain   │◀──│Infrastructure│
└────────────┘   └────────────┘   └────────────┘   └──────────────┘

 

 

 

변경 빈도로 이해하기

가장 안정적인 Domain을 중심으로 자주 변경되는 것들이 Domain에 의존하며 Domain은 외부 변경에 영향받지 않는다.

계층	변경 빈도	예시
Infrastructure	자주 변경	DB 교체, API 버전업
Presentation	자주 변경	UI 개편, API 스펙
Application	가끔 변경	유스케이스 추가
Domain	거의 안 변함	핵심 비즈니스 규칙 추가

 

 

왜 이렇게 하는가?

관점	DIP 미적용	DIP 적용
결제사 교체 시	OrderService 코드 수정 필요	구현체만 교체, 설정 변경
단위 테스트	실제 결제 API 호출됨	Mock 주입으로 빠른 테스트
도메인 순수성	외부 라이브러리에 오염	비즈니스 로직만 존재
컴파일 의존성	infrastructure 변경 시 domain 재컴파일	domain은 영향 없음