기술에 의존적이라는 것에 대해서 조금 질문드립니다.

구현은 Spring Data가 동적으로 해주죠. 인터페이스만 있는 거 맞습니다.

그러면 기술에 의존하는가라고 하면 그렇다고 해야죠. 이름에 Jpa가 들어가자나요. 😄

그런데 인터페이스에 기술과 연관된 게 조금 보이면 뭐가 문제일까요?

어떤 분들은 그러면 다른 데이터 기술로 바꿀 때 고쳐야 하지 않냐고 하죠. 그럼 고치면 되죠.

JpaRepository 말고 그냥 Repository 인터페이스만 쓰는 방법도 있습니다. 그러면 최소한의 인터페이스 메소드만 추가할 수도 있죠.

보신 책은 아주 엄격하게 기술 의존성에 제한을 걸어서 설명을 합니다. 다음 달에 MongoDB로 바꿀 수도 있는데 뭐 이런 식이죠.

여기서부터의 선택은 직접 하시면 됩니다.

중요한 건 내가 클린 아키텍처를 썼는가? 그게 아니고, 어떤 선택을 하면 그게 개발에 어떤 유익을 줄 것인가 이걸 따져보는 겁니다. 이건 상황과 디테일에 따라서 크게 달라집니다.

저도 대부분 JpaRepository를 사용합니다. 가끔 아닐 때도 있습니다. 여러 다른 기술을 같이 쓰거나 전환할 일이 확실한 경우에요.

안녕하세요, 인프런 AI 인턴입니다.

비오님의 질문에 대한 답변으로, 기술에 의존적이라는 관점과 각 인터페이스가 어떤 레이어에 속하는지에 대한 관점을 바탕으로 살펴볼 수 있는 유사한 내용이 답변으로 기존에 제시된 바 있습니다.

의존성 방향과 관련하여 [의존성 방향과 관련된 질문이 있습니다.]에서 토비님께서 제시한 답변에서는, 의존성의 방향이 어떻게 되어야 하는가에 대한 설명과 함께, 이와 관련된 아키텍처의 구성 방법에 대해 다루고 있습니다. 이 답변에서는, 의존성의 방향이 헥사고날(혹은 클린 아키텍처) 아키텍처에서 어떻게 구성되는지에 대한 설명을 통해, 인터페이스의 위치와 기술 의존성에 대해 깊이 있는 통찰을 제공합니다.

토비님은 외부 세상과 내부 애플리케이션으로 구분하고, 외부에서 내부로만 의존하게 하며, 이 경계에 인터페이스(ports)를 두는 방식을 헥사고날 아키텍처라고 설명합니다. 이러한 설명은 인터페이스가 속하는 레이어와 의존성 방향에 대한 근본적인 이해를 돕습니다.

비오님의 질문에서 언급된 상황, 즉 Spring Data JPA를 사용하는 경우와 비즈니스 로직과 영속성 로직의 구분에 대해서는, 토비님의 설명을 통해 인터페이스가 애플리케이션의 핵심 로직을 담당하는 계층(비즈니스 로직이라고 할 수 있는 부분)에 있으면서, 구현체가 영속성 로직을 담당하는 계층(영속성 레이어에 해당하는 부분)에 있다는 점에서, 이들의 의존성 방향이 헥사고날 아키텍처의 원칙을 잘 따르고 있음을 확인할 수 있습니다.

토비님의 답변은 아키텍처 내에서 인터페이스와 구현체가 어떻게 배치되어야 하는지에 대한 중요한 인사이트를 제공하며, 이러한 원칙이 실제 어플리케이션 설계재에서 어떤 의미를 가지는지에 대한 이해를 도울 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.