아키텍처 패턴과 종류
[아키텍처 패턴(Architecture Pattern)]
정의 : 주어진 상황의 소프트웨어 구조에서 발생하는 문제점을 해결하기 위한 일반화된 재사용 가능한 솔루션
아키텍처 패턴은 디자인 패턴보다 더 큰 범주에 속해 있으며 소프트웨어의 전체적인 그림을 만드는 솔루션이라 할 수 있습니다.
기존에 아키텍처 패턴이 정립되지 않고 설계를 하다 보니 개발자간 소스 파악이 너무 힘들고 약속이 제대로 되지 않았습니다. 아키턱처 패턴은 소프트웨어 설계의 기본이며 자주 사용되는 모형들을 정립한 하나의 약속이라고 볼 수 있습니다.
이번 포스팅에서는 기본적으로 자주 사용되는 몇 가지 아키텍처 패턴을 다뤄보겠습니다.
[계층화 패턴(Layer Pattern)]
- n-티어 아키텍처 패턴으로도 불립니다.
- 하위 모듈을 그룹으로 나눌 수 있는 구조화된 프로그램에서 사용할 수 있습니다.
- 각 서브 시스템이 하나의 계층이 되고 하위층이 제공하는 서비스를 상위층의 서브 시스템이 이용할 수 있는 구조입니다.
사용 예시
- OSI 7계층 구조
- E-commerce 웹 애플리케이션
장단점
- 각 층이 구분되어 있기 때문에 필요에 따라 쉽게 바꿀 수 있습니다.
- 계층간 통신 비용이 발생해 성능이 저하될 수 있습니다.
[클라이언트-서버 패턴(Client-Server Pattern)]
- 클라이언트 : 서버에 서비스를 요청하는 객체
- 서버 : 클라이언트에 서비스를 제공하는 객체
- C-S 패턴은 다수의 클라이언트와 하나의 서버로 구성됩니다. 서버는 클라이언트에 서비스를 제공하며 데이터를 관리하는 역할을 합니다.
사용 예시
- 이메일, 문서 공유 등 온라인 애플리케이션
- 일반적인 웹 프로그램 등
[마스터-슬레이브 패턴(Master-Slave Pattern)]
- 이 패턴은 마스터 컴포넌트가 동등한 구조의 슬레이브 컴포넌트로 작업을 분산하고, 슬레이브가 결과값을 반환하면 최종 결과값을 계산하는 구조입니다.
사용 예시
- 컴퓨터 시스템에서 버스와 연결된 주변장치
[파이프-필터 패턴(Pipe-Filter Pattern)]
- 데이터 스트림을 생성하고 처리하는 시스템에서 사용할 수 있습니다.
- 필터 컴포넌트에서 각 처리과정을 실행하며, 처리된 데이터는 파이프를 통해 전송됩니다.
- 파이프는 버퍼링 또는 동기화 목적으로도 사용될 수 있습니다.
사용 예시
- Unix의 쉘 방식
- 컴파일러의 어휘 분석, 파싱, 의미 분석
[브로커 패턴(Broker Pattern)]
- 분리된 컴포넌트로 구성된 분산 시스템에서 사용되는 패턴입니다.
- 각 컴포넌트들은 원격 서비스를 통해 서로 상호작용을 할 수 있으며 브로커 컴포넌트가 컴포넌트 간의 통신을 조절합니다.
- 작동방식 : 서버가 자신의 서비스를 브로커에 넘기고(publish), 클라이언트가 브로커에 서비스를 요청하면 브로커가 자신의 레지스트리에 있는 적합한 서비스로 리디렉션 합니다.
사용 예시
- 메시지 브로커 소프트웨어
[피어 투 피어 패턴(Peer to Peer Pattern)]
- 피어라 부르는 각 컴포넌트 간에 서비스를 주고 받는 패턴입니다.
- 피어는 클라이언트로서 각 피어에게 서비스를 요청할 수 있고, 서버로서 각 피어에게 서비스를 제공할 수도 있습니다.
- 피어 객체 하나가 클라이언트, 서버의 역할을 모두 수행하는 구조입니다.
사용 예시
- 파일 공유 네트워크(P2P)
[이벤트-버스 패턴(Event-Bus Pattern)]
- 이벤트 소스(event source), 이벤트 리스너(~ listener), 채널(channel), 이벤트 버스(~ bus) 4가지 컴포넌트를 갖는 패턴입니다.
- 이벤트 소스 : 이벤트 버스를 통해 특정 채널로 메시지를 발행(publish)
- 이벤트 리스너 : 특정 채널에서 메시지를 구독(subscribe)
- 리스너가 구독한 채널에 소스가 서비스를 제공하면 채널이 리스너에게 서비스를 제공해 주는 구조입니다.
사용 예시
- 안드로이드 개발
- 알림 서비스(Youtube?)
[모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern) - MVC Pattern]
- 모델 : 도메인의 기능과 자료를 저장, 보관
- 뷰 : 사용자에게 결과를 표시(하나 이상 정의 가능)
- 컨트롤러 : 사용자로부터 입력과 상호작용을 처리
- 3개의 각 컴포넌트는 각자의 역할을 갖고 사용자에게 서비스를 제공합니다.
- 기능마다 컴포넌트를 나눈 이유는 사용자 인터페이스(뷰)가 모델과 컨트롤러 보다 더욱 자주 변경되기 때문입니다.
- 또한 자료의 저장, 제어 기능과 표현 기능을 분리하여 재사용을 증진시키기 위함입니다.
사용 예시
- 일반적인 웹 애플리케이션 설계 아키텍처
[블랙보드 패턴(Blackboard Pattern)]
- 명확히 정의된 해결 전략이 알려지지 않은 문제에 대해서 유용한 패턴입니다.
- 부분적인 해법, 대략적인 해법을 수립하기 위한 서브시스템의 지식을 조합하는 방법입니다.
- 블랙보드 : 중앙 데이터 저장소
- 지식 소스(knowledge source) : 특수한 문제를 해결하는 독립 서브시스템
- 제어 컴포넌트(control component) : 변경을 모니터링하고, 다음 동작을 결정
- 모든 컴포넌트는 블랙보드에 접근하여 새로운 데이터 객체를 생성할 수 있습니다.
- 공유 데이터 구조 위에서 종합적으로 동작하는 독립적인 프로그램을 모은 방법입니다.
- 각 프로그램은 전체 중 특정한 부분을 해결하기 위해 특수화 되어있습니다.
- 제어 컴포넌트는 현재 처리 과정을 평과하여 특수화 된 프로그램을 조율합니다.
사용 예시
- 음성 인식
- 차략 식별 및 추적
- 수중 음파 탐지기 신호 해석
[인터프리터 패턴(Interpreter Pattern)]
- 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용되는 패턴입니다.
사용 예시
- DB 쿼리 언어
- 통신 프로토콜 정의 언어
[참고 자료]
- 10가지 소프트웨어 아키텍처 패턴 : https://mingrammer.com/translation-10-common-software-architectural-patterns-in-a-nutshell/#%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90-%ED%8C%A8%ED%84%B4-%EB%B9%84%EA%B5%90
- 10가지 소프트웨어 아키텍처 패턴(영문) : https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013