의존 관계

의존관계란 무엇인가…🤔
개발하면서 정말 많이 겪게 되는 단어다.

의존이란,

다른 컴포넌트, 모듈의 클래스나 변수, 메소드 등을 사용할 때 형성되며, 사용하는 쪽에서 사용되는 쪽으로 의존하는 관계가 형성된다.

이 의존관계는 강하게 의존할 수록 변경, 수정에 있어서 많은 자유롭지 못하며 이러한 작업을 진행할 때 많은 리소스를 요구한다.
즉 의존관계가 강할 수록 유지보수에 어려움이 있다.

이번 포스팅에서 주로 다룰건 아래에서 다룰 의존 역전이다. 그래서 의존관계에 대한 자세한 예시는 스킵하도록 하겠다. (인터넷에 자료가 정말 많아요…😢)

의존 역전

의존 역전이란,

고수준 모듈에서 저수준 모듈을 의존하지 않는 것

이런 의미인데, 이렇게만 보면 참.. 무슨 소린지 알기 어렵다 😓

쉽게 설명하기 위해 백엔드에서 주로 다루는 계층형 아키텍쳐를 통해 해당 설계의 구성과 이유를 설명하며 의존역전의 적용을 말해보겠다 👍

보통 계층형 아키텍쳐를 설계할 때 위와 같은 그림처럼 설계한다.

우선 여기서 저수준 모듈은 어떤 계층일까? 🤔
바로 Presentation 과 Infrastructure 계층이다. 특정 기술(HTTP, Database…등)을 사용하며 그러한 기술에 의존하기 때문이다.

그렇다면 고수준 모듈은 Applicaiton 과 Domain 이 되는데 이 중에서 Domain 은 핵심적인 비즈니스 로직, 엔티티를 포함하고 있기 때문에 가장 고수준 모듈이라고 볼 수 있다. 이렇게 도메인을 중심으로 설계를 이어가는게 DDD(도메인 주도 설계)인데… 이 부분에 대해서는 아직 공부해 볼 것이 많아서, 다음에 다루도록 해보겠다 🤚

즉 위 그림은 의존 역전의 원칙(DIP)을 잘 지키고 있는 모습이라고 할 수 있다

보통은 JPA 를 사용해서(Hibernate 구현체) Repository 의 구현체에 위치시키는 Infrastructure 에 대해서 의아할 수 있다. 간단하게 예시를 들자면 QueryDsl 이 있겠다. QueryDsl 에 대한 구현체 같은 경우는 Infrastructure 에 넣는다고 보면 될 것 같다 🫡

필자의 궁금한점

애플리케이션이 이렇게만 구성된다면 딱히 문제가 안된다. 하지만 개발을 하다 보면 이렇게 단순한 구성만 존재하지 않는다 😓
특히 Infrastructure 에서는 JWT 나 OAuth 같은 경우는 바로 다른 Layer(필자는 보통 Application layer) 에서 사용되는데, 이런 경우는 JWT 나 OAuth 가 사용되는 모듈을 인터페이스로 추상화해서 사용한다면 해당 모듈을 Application → Infrastructure 의 의존관계가 DIP 를 위반하지 않는 것인가 궁금하다 🤔