[Bottler] 서비스 순환 참조 및 직접 참조 에 대해 고민한 점

Facade Pattern

Facade Pattern을 통해 순환 참조를 해결하고 DTO 변환 역할을 위임해 Facade Service에서 사용되는 Service들은 순수 Domain만 반환하게 하면 괜찮지 않을까?

[ Controller ]  
      ↓  
[ Facade Service ]  
      ↓  
[ Service ]  
      ↓  
[ Domain ]  
      ↑  
[ Repository 인터페이스 ]  
      ↑  
[ RepositoryImpl (Infra) ]  
      ↑  
[ Entity (Infra) ] ← [ JpaRepository ]  
      ↓  
[ Database ]

 

적용 고려 상황

• 서비스 레벨에서 Facade Pattern는 복잡한 비즈니스 로직이 여러 서비스에 걸쳐 있을때 적합합니다.
• 비즈니스 로직의 중복을 방지하는 용도로도 쓴다고 합니다.

 

역할

• 복잡한 기능들을 간단한 인터페이스로 제공함으로써 개발자가 내부 로직의 복잡성을 몰라도 되게 함
• 예: 운전 할 때 가속 시 가속 페달만 밟으면 되지 밟을 때 내부적으로 어떤 동작들이 일어나는지는 알 필요 없음.
• 각 서비스는 순수 Domain만 반환하고 Facade Service에서 DTO변환 담당

 

고려할 점

• 각 서비스가 개별 책임을 유지하는지 확인해야 하고
• 조합 용도로 써야하지 세부 책임을 가지면 안됩니다
• 하나의 퍼사드가 지나치게 많은 기능을 갖지 않도록 관리해야하고
• 여러 퍼사드 클래스로 나누어 응집도를 유지해야 한다고 합니다 => 관리할게 늘어난다는 소리라 단점 같네요
• 퍼사드가 단순히 서비스를 전달하는 역할만 하면 직접 호출을 고려하는게 더 효율적일 수  있습니다.

 

장점

• 복잡한 로직을 단일 진입점으로 단순화 할 수 있고
• 팀 전체에서 통일된 비즈니스 흐름이 필요하면 여러 서비스 호출 흐름이 동일 해지면서 유지보수가 쉬워집니다
• 퍼사드 서비스를 통하기 때문에 순환 참조를 제거할 수 있습니다.

단점

• 팀 전체가 쓰지 않을 경우
  1. 일관성 부족: 어떤 곳은 쓰고 어떤 곳은 안쓰고 하면 구조가 섞이게 됩니다.
  2. 코드 관리 어려움: 복잡한 로직들이 여러 Service에 분산되기 때문에 관리하기가 어렵고
  3. 불필요한 래핑: 단순 서비스 로직을 불필요하게 Facade Service로 감싸는 경우도 발생할 수 있다고 합니다.
  4. 변경 비용 증가: 서브 서비스가 크게 변경된다면 퍼사드도 맞춰서 변경해야 하기 때문에 유지보수의 복잡성을 증가시킬 수 있습니다.

결론

• 복잡한 로직이 여러 서비스에 걸쳐 있는 경우
• 중복 로직을 방지하고 팀 전체의 흐름을 통일해야 하는 경우
• 순환 참조를 제거하면서 로직을 간결하게 해야하는 경우

 

HelperService

그러면 HelperService를 사용하는건 어떨까?

• 각각 서비스의 필요한 공통 로직을 받고 분리해서 서비스간의 직접적인 의존 제거를 제공합니다.

 

고려 상황

• 단순 공통 기능이 여러 서비스에서 반복될 때
• 서비스 간 직접 의존을 제거하면서 공통 로직을 재사용해야 할 때

 

장점

• 간단하고 명확함: 서비스 간 공통된 기능만 분리하는거라 구조가 단순
• 재사용성: 여러 서비스가 공통 로직을 재사용할 수 있음
• 순환 참조 제거

단점

• 퍼사드 패턴보다 기능이 단순함
• 다른 비즈니스 로직과 겹칠 수 있어 한계가 있음

 

인터페이스 분리

Service Interface와 Service Interface 구현체를 둬서 순환 참조 문제를 해결할 수 있지 않을까 하는 의견

 

고려 상황

• 서비스 간 양방향 의존 관계가 필요할 경우
• 순환 참조 문제를 해결하면서 각 서비스의 독립성을 유지하고 싶은 경우

 

장점

• 순환 참조 해결: 직접 참조 대신 인터페이스를 통해 의존성을 간접화 함
• 유연한 구조: 구현체를 바꾸기 쉬워지고 테스트 용이성이 향상 됌

단점

• 구조의 복잡성: 인터페이스를 분리하면 클래스와 인터페이스의 수가 늘어날 수 있음
• 오버 엔지니어링 위험: 단순한 의존 관계에 인터페이스를 적용하면 불필요하게 복잡해질 수 있음

 

결론

• 양방향 의존 관계가 불가피한 상황에서 순환 참조를 해결해야 할 때
• 유연성과 확장성을 중시할 때

 

최종결론

• 단순한 공통 기능: HelperService
• 복잡한 서비스 호출 및 단일 진입점 설정: Facade Pattern
• 양방향 의존성 필요: 인터페이스 분리
• 제일 좋은건 순환참조 생기는 설계 자체를 하지 않는 것