안녕하세요! 꽤나 심도 깊은 질문을 해주셔서 조심스럽게 저의 의견을 남겨봅니다. 의존성 역전 원칙의 가장 큰 목적은 변동성이 큰 구현체로부터의 영향을 없애기위한 목적이 크죠. 그리고 이 목적이

안녕하세요! 꽤나 심도 깊은 질문을 해주셔서 조심스럽게 저의 의견을 남겨봅니다. 의존성 역전 원칙의 가장 큰 목적은 변동성이 큰 구현체로부터의 영향을 없애기위한 목적이 크죠. 그리고 이 목적이 빛을 발하려면 말씀하신 것처럼 추상화와 구현체의 관계가 1:1 이 아닌 1:N 으로 구현체가 존재하고 이를 활용할 수 있어야 합니다. 개인적인 생각으로 운영하는 서비스의 규모나 사업의 방향성 혹은 요구사항에 따라 질문자님의 생각처럼 추상화를 두는것이 의미가 없을수도 있습니다. 하지만 계속 그런 상황이 유지될 거라는 보장은 없습니다. 서비스의 규모가 갑작스럽게 커져 개선이 필요하거나 사업의 방향성으로 다양한 요구사항이 생길 경우 케이스에 따라 Business Layer 와 Persistence Layer 에 추상화를 도입해야할 수도 있습니다. 저의 경우 하나의 소스코드로 글로벌 인스턴스 환경을 운영하는 케이스에서 활용했던 경험이 있는데요, 각 나라의 환경별로 서비스 요구사항이 조금씩 다르고 연동해야할 외부 시스템이나 Database 종류 및 구성, 스키마가 다른 부분들이 생겨 Business Layer 와 Persistence Layer 의 클래스를 추상화로 정의하고 각 환경별로 구현체를 다르게 가져가야 했습니다. Business Layer 를 추상화하지 않을거면 Repository Class 도 추상화를 하지 않는다는것도 상황에 따라 달라질 수 있습니다. Mybatis 를 쓰다가 JPA 혹은 캐시를 도입하는등의 Repository 관련 기술 스택 변경을 시도할 때 기존 기능에 대한 이슈가 없는지를 보기 위해 이전 기술 스택과 신규 기술 스택을 병행해서 운영해볼 경우 비지니스 로직에 대한 변경은 없기 때문에 Business Layer 의 추상화는 필요 없지만 Repository Class 의 추상화는 필요하게 됩니다. 결론을 맺자면, 상황에 따라 추상화를 하는 것이 도움이 될수도 의미가 없을수도 있습니다. 하지만 그 상황이란게 질문자님의 생각처럼 추상화와 구현체가 1:1로 구현되는 상황만 유지될거라는 보장은 없기 때문에 미리 추상화를 해두면 그러한 상황이 닥쳤을때 좀더 유연하게 대처가 가능하다라고 말씀드리고 싶습니다. 하지만 무조건 추상화를 해야하냐 라고 물으신다면 그건 취사선택이라 생각됩니다. 팀 혹은 회사의 판단하에 그럴일이 없을것 같아 나중에 추상화가 필요한 상황이 생겼을때 하자 라고 하면 그때 해도 되는것이고 혹시 모르니 미리 해두자고 결론이 나면 추상화를 미리 해도 된다 생각합니다. 제 의견은 여기까지 입니다. 나름 열심히 정리해봤는데 질문에 맞게 잘 설명했는지 모르겠네요^^;; 부디 저의 작은 의견이 조금이나마 도움이 되시길 바라겠습니다.