인터페이스는 사용하는 클래스에 가장 가까이 두는 걸로 이해했습니다. 하지만 그 인터페이스를 사용하는 클라이언트가 많다면 어떻게 해야할까요?

Question

강의 재밌게 잘 보고 있습니다.
궁금한 게 있어 질문드립니다.

인터페이스는 구현체와 같은 모듈에 두는 게 아닌, 사용하는 클래스에 가장 가까이 두는 걸로 이해했습니다.
하지만 그 인터페이스를 사용하는 클라이언트가 많다면 어떻게 해야할까요?

예를 들어
Payment 패키지의 PaymentService 도 ExRateProvider 를 쓰고,
XXX 패키지의 XXXService 도 ExRateProvider 를 쓴다면
ExRateProvider 의 모듈 위치는 어디에 존재를 해야할까요? 아니면 다른 방법이 있을 듯 한데, 그 방법은 무엇일까요?

ExRateProvider 의 모듈 위치가 클라이언트와 분리되어 있다면, DIP 적용 이전 그러니까 WebApiExRateProvider 와 ExRateProvider 가 한 모듈에 같이 위치한 그림과 별반 다를 것이 없다(모듈 의존성에 따른 변경 가능성) 생각이 들어서요

토비 · Answer

인터페이스를 구현과 분리하는 방식을 쓸 때, 기본적으로는 인터페이스의 클라이언트와 인터페이스를 가까이 둡니다. 그런데 인터페이스를 사용하는 클라이언트가 여러개라면? 이 때는 별도의 위치로 분리하는 수 밖에 없죠. 중요한 건 모듈 레벨에서, 혹은 계층 레벨에서 클라이언트와 같은 레벨에 두는 겁니다. 구현과 함께 또는 가까운 쪽이 아니고요. 패키지는 분리될 수 있겠지만요.

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. 글러브님의 질문에 답변드립니다. 여러 클라이언트가 사용하는 ExRateProvider 인터페이스의 모듈 위치에 대한 고민은 흔히 마주치는 설계 문제입니다. 이런 경우, 인터페이스를 도메인 서비스나 공통 인터페이스 모듈 등, 여러 클라이언트가 접근 가능하고 공유할 수 있는 중앙집중화된 위치에 두는 것을 고려해볼 수 있습니다. 인터페이스를 중앙에 위치시키면 클라이언트는 인터페이스 모듈만 의존하게 되어, 구현체의 변경이나 다른 구현체의 추가가 클라이언트 코드에 직접적인 영향을 미치지 않습니다. 이는 의존성 역전 원칙(Dependency Inversion Principle, DIP)을 적용하여 각 모듈의 결합도를 낮추고, 확장성 및 유지보수성을 향상시키는 데 도움이 됩니다. 또한, 공통 인터페이스 모듈의 도입은 인터페이스 재사용성을 증가시키고, 프로젝트 전반에서 일관된 인터페이스 사용을 유도하여, 전체적인 코드의 일관성과 가독성을 향상시킬 수 있습니다. 단, 이 방법을 적용할 때는 모듈 간의 의존성 관리, 배포 및 버전 관리에 주의할 필요가 있습니다. 중앙 인터페이스 모듈의 변경이 여러 클라이언트 모듈에 영향을 줄 수 있으므로, 인터페이스 변경 사항을 관리하고, 필요한 경우 버전 관리를 통해 호환성을 유지하는 방안을 고려해야 합니다. 최종적으로, ExRateProvider 인터페이스의 모듈 위치는 프로젝트의 구조, 유지보수성, 확장성 및 팀의 선호도를 고려하여 결정하는 것이 좋습니다.