본문 바로가기

Design/Design Pattern

[Design Pattern] Facade Pattern

이번 장에서는 퍼사드(Facade) 패턴에 대해서 알아보도록 한다.
샘플 코드는 여기 (링크) 프로젝트의 테스트 코드로 정리해두었다.


퍼사드 패턴이란?
위키백과에 따른 정의는 아래와 같다.

Facade (외관)은 "건물의 정면"을 의미한다.
클래스 라이브러리 같은 어떤 소프트웨어의 다른 커다란 코드 부분에 대한 간략화된 인터페이스를 제공하는 객체이다.

쉽게 말하면 실제로 복잡하게 작동하는 로직이 있을 때 복잡한 로직을 수행하는 외관(Facade)를 두고
클라이언트는 외관을 호출하여 처리하게 하는 패턴이다.

필자는 CI/CD의 복잡한 모든 단계를 개발자가 직접하는 호출해서 진행하는 과정을
Facade 객체인 CICDFramework를 생성하여 복잡한 단계 수행을 Facade 객체에게 위임하는 상황을 예로들어 진행한다.

CI/CD가 친숙하지 않다면 내가 만든 코드가 복잡한 과정들을 거쳐서 서버에 배포되는 일련의 과정들이 자동화 되어 있는 것 정도로만 이해해도
이번 디자인 패턴을 이해하기에는 충분할 것이다.


GoF Design Patterns에 따르면 아래와 같은 Class Diagram이 그려진다.

Facade 클래스는 Class, Class2, Class3 객체를 가지고 있으며 이들을 통해 복잡한 프로세스를 처리한다.

위의 그림을 CI/CD 과정에 적용하면 아래와 같은 Class Diagram이 그려질 것이다.

GitClient: 개발자가 만든 코드를 push하고 서버에 있는 코드를 pull하는 역할을 한다.
JarBuilder: Code를 실행 가능한 Jar 파일로 변환하는 역할을 한다.
DockerClient: Jar파일을 Docker 환경에서 실행가능한 DockerImage로 변환하는 역할을 한다. DockerImage를 Image 저장소에 push하는 역할을 한다.
Deployer: Image 저장소에 있는 DockerImage 파일을 서버에 배포하는 역할을 한다.
CICDFramework: 위에 명시된 객체들을 가지고 있으며 복잡한 CI/CD 과정을 처리한다.


코드를 보면서 하나씩 살펴보도록 한다.

GitClient Class
Class Diagram의 설명 참고

JarBuilder Class
Class Diagram의 설명 참고

DockerClient Class
Class Diagram의 설명 참고

Deployer Class
Class Diagram의 설명 참고

CICDFramwork Class
Class Diagram의 설명 참고

Developer Class
먼저 퍼사드 패턴이 적용되지 않았을 때의 개발자의 배포 과정이다.
필요한 객체들을 모두 생성하여 정해진 프로세스에 맞게 개발자가 직접 진행해야한다.

퍼사드 패턴이 적용되면 아래와 같이 간단해진다.
Git Repository에 push가 성공하면 Facade 객체인 CICDFramework에게 다음 작업 진행을 위임한다.

두 경우의 결과는 아래와 같이 동일하다


지금까지 복잡한 CI/CD 과정을 주제로 퍼사드 패턴에 대해서 알아보았다.
글을 모두 작성하고 보니 CI/CD와 Docker가 친숙하지 않은 개발자들에게는 불편한 글일 수 있을듯 하다.
추후에 다른 주제로 재작성하도록 하겠다.