Server/Spring

[Spring] 계층형 구조의 단점을 보완한 Facade Pattern 적용하기

SeorinY 2023. 7. 21. 22:30

Controller - Service - Repository 계층형 구조로 프로젝트를 진행하던 도중, Service 들끼리 참조하여 이중참조 에러를 경험했다.

처음 이 에러를 마주했을 때, Bean LifeCycle 이 객체 생성 -> 의존관계 주입 순으로 진행되기 때문에 순환 참조가 왜 문제가 되는지 의아했다. 찾아본 결과 의존 관계 주입 방식이 필드 혹은 Setter면 생성 후 의존 관계 주입이 진행돼서 오류가 나지 않지만, 생성자로 의존관계를 주입받을 경우 생성자들이 서로를 순환 호출하여 문제가 발생하는 것이다!!

 

즉, 수직적인 구조로 이뤄진 Service들이 아닌 수평적인 구조의 service들이 모여 생성자로 서로의 의존관계를 주입받을 시 에러를 발생시킬 수 있다는 것!!

 

순환 참조 문제를 해결하기위해 Setter 혹은 필드로 의존관계를 주입받는 디자인 패턴을 선택해야만 할까?

아니면 service 가 repository 만을 가지고, <optional> 타입을 처리해주는 똑같은 코드를 모든 서비스에 작성해줘야할까?

 

위와 같은 고민을 하던 중 Facade 패턴을 발견했다.

 

Facade 란 건물의 정면이라는 뜻으로, 사용하기 복잡한 클래스 라이브러리에 대해 사용하기 편하게 단순화된 인터페이스를 제공해주는 구조적 디자인 패턴이다.

 

계층형 구조에서 Facade 패턴의 계층들은 서로를 참조하지 않으며, 복잡하게 얽혀있는 Service(Provider)들을 Facade 계층에서 서브 시스템으로 가져가고 조합하여 클라이언트에게 간단하게 제공한다.

 

Facade 패턴과 Adapter패턴과의 차이점에 대해 궁금할 수 있지만 Adapter 패턴과는 명백한 차이점이 있다!

Adapter는 특정 클래스 인터페이스를 클라이언트에서 요구하는 다른 인터페이스로 변환하는데 사용되는 디자인 패턴이다.

 

내가 이해한 바로는 클라이언트 입장에서 usecase를 모아둔 것으로 facade 계층을 구성하면 될 것 같다!!

 

Facade 패턴을 사용함으로써 service들의 이중참조를 막으면서 동시에 service들의 책임을 한 단계 더 간단하게 만들 수 있을 것 같다.