인프라스트럭처 의존에 대한 문제 ‘테스트 어려움’, ‘기능 확장의 어려움’ 이라는 두가지 문제에 대한 해결방안으로 제시

Intro

• Service 는 고수준으로 여러 형태의 저수준 Infrastrcture를 이용할 수 있다
• 이때 계층 구조는 여러 Infrastructure를 의존하므로 ‘테스트 어려움’, ‘기능 확장의 어려움’ 이라는 문제를 안게된다
• DIP는 이 문제를 해결하기 위해 저수준 모듈이 고수준 모듈에 의존하도록 바꾼다
  • 다시말해, 저수준의 Infrastructure는 interface 화 아래 감추고
  • 고수준의 Service는 생성자 주입으로 interface의 구현을 받는다
  • “어댑터 패턴이 이렇게 쓰이는구나~”
• DIP의 문제 해결측면
  • 기능 확장의 어려움 (구현 교체의 어려움)
    • 구현 기술을 변경하더라도 인터페이스의 구현체만 교체하면 됨
  • 테스트 어려움
    • 목킹 시, 인터페이스 메소드만 목킹하면 되므로 교체해도 테스트가 변경 없이 갇히게된다.

2.3.1 DIP 주의사항

• 단순히 인터페이스와 구현 클래스의 분리가 아니다.
• 도메인 영역이 인프라르 의존하게만들면 안됨

2.3.2 DIP 와 아키텍처

• DIP 를 항상 적용할 필요는 없다
  • DIP 를 도입했을 때 얻는 이점을 고려하여 적용범위를 검토하자
    • 얻는 이점: 구현의 교체, 테스트 용이성
      • 구현의 교체가 많이 일어날 수도 있는 곳에서 적용하면 좋지 않을까
      • 반드시 최신 트렌드를 따라갈게 아니라 현재 상황에 맞는 것을 선택할 필요가 있다는 것을 느끼는 대목