실무에서 퍼사드 패턴을 적용시키나요? 해당 패턴에 대한 의견이 궁금합니다.

Question

우선 현재 스프링부트 + JPA 사용해서 개발 중입니다.패키지 설계를 하는데, 해외 자료를 몇 개 찾아보다가 발견한 게 Facade(퍼사드)를 정의하는 코드들이 몇 개 보이네요.이를 테면public class MemberFacade { public MemberResponse registerMember(MemberRequest request) { // 1. 중복 회원 검증 // 2. 회원 등록 // 3. 환영 이메일 발송 // 4. 초기 포인트 지급 // 등의 복잡한 로직을 하나의 메소드로 캡슐화 } }위 코드처럼 퍼사드 하나를 두게 되면,service layer에는 각각의 고유 기능에 대한 로직만 정의하고실제 Facade 단위로 묶어서 controller와 service 사이에 두고 호출한다면캡슐화가 되어 있어서 도메인 주도 설계에 좀 더 가까워 지지 않을까? 라는 생각을 하긴 하는데실무에서 어떨지 모르겠습니다.우선 저희 회사는 적용되지 않은 방법이라, 자료를 찾아보는데 딱 체감이 되는 글들이 없네요.프로젝트는 개인 프로젝트이며, 일단 모놀리식으로 구축하다가 개별기능 하나씩 msa로 분해해서 재구성하고 실서비스 테스트도 해볼 예정입니다.의견 주시면 감사하겠습니다.

김포포 · Answer

디자인 패턴은 어떻게 구현했냐가 아니라 어떤 의도를 가지고 있냐가 중요합니다.즉 그런 의도가 있으면 그 패턴인거죠. (구현 모양은 별로 중요치 않습니다)아래를 참고하시면 될 거 같습니다.GoF의 퍼사드 패턴 의도:서브시스템 내의 복잡성을 클라이언트에 숨기기: 여러 클래스로 이루어진 서브시스템은 클라이언트에게 복잡하게 보일 수 있습니다. 퍼사드는 이러한 서브시스템 전체를 감싸는 간단한 인터페이스를 제공하여 클라이언트가 필요한 기능에 쉽게 접근할 수 있도록 합니다.클라이언트와 서브시스템 간의 결합도 줄이기: 클라이언트가 직접 서브시스템의 여러 클래스와 상호작용하게 되면 결합도가 높아져 서브시스템의 변경이 클라이언트에 큰 영향을 미칠 수 있습니다. 퍼사드를 통해 클라이언트는 퍼사드와만 상호작용하므로 서브시스템 내부의 변경으로부터 보호받을 수 있습니다.서브시스템을 계층 구조로 만들기: 퍼사드를 사용하면 서브시스템 위에 상위 수준의 인터페이스를 정의할 수 있습니다. 이를 통해 시스템을 더 쉽게 이해하고 사용할 수 있는 계층 구조로 만들 수 있습니다.일관성 없는 인터페이스를 통합: 여러 서브시스템이 제공하는 인터페이스가 일관성이 없을 때, 퍼사드는 이를 통합하여 클라이언트에게 일관된 사용 경험을 제공할 수 있습니다self4j logback 관계를 GoF의 의도와 비교했을 때:복잡성 은닉: SLF4J는 다양한 로깅 프레임워크의 고유한 설정 및 사용 방식을 추상화하여 개발자가 로깅 시스템의 내부 구조를 알 필요 없이 편리하게 사용할 수 있도록 합니다.결합도 감소: 개발자가 SLF4J API에 의존하도록 함으로써, 특정 로깅 프레임워크에 대한 직접적인 의존성을 줄입니다. 따라서, 나중에 로깅 프레임워크를 변경하더라도 애플리케이션 코드를 크게 수정할 필요가 없습니다.일관성 없는 인터페이스 통합: 각 로깅 프레임워크는 고유한 API를 가질 수 있지만, SLF4J는 이를 하나의 일관된 인터페이스로 통합하여 개발 편의성을 높입니다.따라서 SLF4J와 Logback의 관계는 퍼사드 패턴의 좋은 예시라고 할 수 있습니다. SLF4J라는 퍼사드를 통해 개발자는 하위의 다양한 로깅 구현체(그중 하나가 Logback)의 복잡성을 숨기고, 통일된 방식으로 로깅 기능을 사용할 수 있습니다. 이는 시스템의 유연성과 유지보수성을 향상시키는 데 기여합니다.결론)- 많이 사용된다.- 제가 보기에 님의 코드는 퍼사드패턴이라 부르면 안된다.(오히려 진짜 패턴 잘 아는 사람들에겐 혼동만 줄 뿐이고, 패턴 공부를 안한 사람들에겐 알 수 없는 단어) "퍼사드 느낌으로" 정도면 괜찮을 듯ps) 웹백엔드 개발에서 특히 자바진영에서 마음데로 가져다 붙여서 쓰느라... 의사소통의 도구로써는 옅어진듯..즉 "의도" 가 귀에 걸면 귀걸이 코에 걸면 코걸이가 된 느낌...저런 것 까지 퍼사드 패턴이라고 부르는거가 개인적으론 탐탐치는 않으나, Gof가 법도 아니고 나온게 1990년대 초중반이니..나름 이해는 감..

장독깨기 · Answer

위 댓글에서 퍼사드 패턴의 목적을 잘 설명해주셨네요.지금 하고자 하는 것이 그 목적에 부합하는지 생각해보면 될 거 같습니다.

초무쿤 · Answer

Service > 다른 Service 호출하는걸 Facade로 말씀하신건가요?그런거면 대부분 복잡한 업무시스탬들에서는 그렇게 사용하는데 굳히 파사드 패턴이라고 정의 내리지는 읺아요.그냥 대부분이 그런식이라. 뭐 가끔 건살팅 하시는분들이 파사드 패턴으로 설명하시는 경우도 있긴한데..보통은 조금 큰 범주로 CBD(Component Based Development) 라는 개념으로 이야기하는 경우가 많았던거 같네요.

scissors hand · Answer

제가 봤을 땐 본문에 제시한 예제가 훌륭한 Facade 패턴 예를 들어 주신 거 같습니다만...?중복회원 검증, 회원 등록 같은 건 MemberService환영 이메일 발송은 EmailService초기 포인트 지급은 PointServicehttps://curiousjinan.tistory.com/entry/facade-pattern-explained

호두까면주름생김 · Answer

Q: 실무에서 퍼사드 패턴을 적용시키나요?A: 안함Q: 해당 패턴에 대한 의견이 궁금합니다.A: 건설적인 고민이 될 순 있으나, API 특성이 단방향이고 모놀리스식 구조체면 굳이 안해도 된다고 생각함. 퍼사드로 애플리케이션 비지니스 로직의 게이트웨이로 만드는건 좋은데, 그럴려면 해당 Service 들이 도메인 하위의 서비스로 잡혀 있어야 돌려가면서 쓸수 있음. 근데 코드 변경건도 "남이 만든건 건들지마라" 라는 실무의 암묵적 룰이 있는 곳에서 파일의 폴더 위치 또는 패키지 위치를 선정하는 것은 어림 반푼어치도 없는 말임. 퍼사드가 제대로 된 역할을 하려면 해당 모듈 또는 패키지 또는 서버가 자신만의 고유한 관심사를 가지고 있어야하고, upstream, downstream 의 경계를 확실히 잡아줘야 비로서 빛이 난다고 생각함.위 코드는 퍼사드 패턴의 의도를 잘 구현한듯.

실무에서 퍼사드 패턴을 적용시키나요? 해당 패턴에 대한 의견이 궁금합니다.

5개의 답변

#mvc 목록