[투표] Service Layer 인터페이스 도입에 대한 아키텍처 논의

[mainlib990]

안녕하세요, 팀원 여러분. 'Package by Feature' 구조를 채택한 우리 프로젝트에서 Service Layer의 설계 방식에 대한 기준을 정립하고자 합니다.

논의할 주제는 "Service Layer를 인터페이스와 구현체로 분리할 것인가, 아니면 구현체 클래스만으로 구성할 것인가" 입니다. 특히 일부 서비스들이 다른 Feature의 서비스를 호출해야 하는 공유 관계가 존재하기에, 이 점을 고려한 장기적인 설계 방향을 결정해야 합니다.

아래 두 가지 안을 읽어보시고, 우리 프로젝트의 유지보수성과 확장성을 고려했을 때 더 적합한 방식에 투표해 주세요.

---

📝 안건 1: Service Layer를 인터페이스(Interface)와 구현체(Class)로 분리한다.

• 구조: MemberService (인터페이스)와 MemberServiceImpl (구현 클래스)로 분리
• 설명: Service의 역할(API)을 인터페이스로 명확히 정의하고, 실제 로직은 구현체 클래스에 작성합니다. Controller나 다른 Service는 구현체가 아닌 인터페이스에
  의존합니다.

장점

• 느슨한 결합 (Loose Coupling): 의존성 역전 원칙(DIP)에 따라, Service를 사용하는 측은 실제 구현을 몰라도 되어 유연성이 높아집니다.
• 테스트 용이성: 단위 테스트 시 Mock 객체를 주입하기 쉬워져, 독립적인 테스트 환경을 구축하는 데 유리합니다.
• Feature 간 의존성 관리: 다른 Feature의 Service를 호출할 때, 해당 Service의 구현체가 아닌 인터페이스에만 의존하게 됩니다. 이는 Feature 간의 결합도를 낮춰, 한쪽의 내부 구현 변경이 다른 쪽에 미치는 영향을 최소화합니다.
• AOP 적용 유리: Spring의 @transactional과 같은 AOP 기능은 JDK Dynamic Proxy를 사용하는 경우 인터페이스 기반으로 동작하므로, 프록시 패턴 적용에 용이합니다.

단점

• 코드량 증가: 모든 Service마다 인터페이스와 구현체, 총 2개의 파일을 만들어야 하므로 코드량이 늘어납니다.
• 과잉 설계 가능성: 구현체가 하나뿐인 단순한 Service의 경우, 불필요한 추상화 단계가 추가된다고 느낄 수 있습니다.

---

📝 안건 2: Service Layer를 인터페이스 없이 구현체 클래스만으로 사용한다.

• 구조: MemberService (구현 클래스)만 존재
• 설명: 인터페이스 없이 클래스로 Service를 바로 구현합니다. Controller나 다른 Service는 이 구현체 클래스에 직접 의존합니다.

장점

• 단순성 및 개발 속도: 구조가 단순하고 파일 수가 적어 초기 개발 속도가 빠릅니다.
• 직관적인 코드: 인터페이스와 구현체를 오갈 필요 없이, 코드 추적이 직관적입니다.

단점

• 강한 결합 (Tight Coupling): Service를 사용하는 측이 구체적인 구현 클래스에 직접 의존하게 되어 결합도가 높아집니다.
• Feature 간 강한 결합: 다른 Feature의 Service를 호출할 때, 해당 Service의 구현 클래스에 직접 의존하게 됩니다. 이는 Feature 간의 의존성을 강하게 만들어, 향후 리팩토링이나 구현 교체를 어렵게 할 수 있습니다.
• 테스트의 어려움: Mocking 프레임워크의 도움 없이 순수 단위 테스트를 작성하기가 더 까다로워질 수 있습니다.

---

🗣️ 중점 논의사항

우리의 '서비스 간 공유' 상황에서, 기능(Feature) 패키지 간의 결합도를 어떻게 관리하는 것이 장기적으로 유리할까요? 인터페이스를 통한 느슨한 결합이 주는 이점이 코드량 증가라는 단점을 상쇄할 만큼 크다고 생각하시나요?