아키텍처 스타일 vs 아키텍처 패턴 vs 디자인 패턴

George Fairbanks 와 Michael Keeling 및 Wikipedia에서 말하는 바에 의거, 아키텍처 스타일과 아키텍처 패턴은 스코프에서 차이가 있다는 점에서 이 포스트를 정리함.

우선 아키텍처 스타일과 아키택처 패턴 그리고 디자인 패턴은 상호 배타적이지 않고 보완적이며 필요할 때만 쓰여야 함을 밝힘.

아키텍처 스타일

• 코드를 구성하는 방법을 매우 광범위하게 알려준다.
• 최고 수준의 세분성을 가지며 계층(layer), 앱의 상위 레벨 모듈을 지정.
• 위의 모듈들과 계층들이 상호 작용하는 방식과 관계 또한 지정.
• 예시 ↓
  -Component-based
  -Monolithic application
  -Layered
  -Pipes and filters
  -Event-driven
  -Publish-subscribe
  -Plug-ins
  -Client-server
  -Service-oriented
• 특정 기술 환경(Microservices 는 Docker, Kubernetes 사용), 정책( 규칙이나 가이드라인; 보안/데이터 처리/코드 리뷰 등), 프레임워크 혹은 개발 관행에 따라 구현 방법이 달라짐.

아키텍처 패턴

• 설계 단계에서 제공
• 패턴이란? 반복적인 문제를 해결하기위한 반복적인 해결책. 따라서 아키텍처 패턴은 아키텍처 스타일의 해결책을 의미.
• 아키텍처 스타일을 구현 및 관련 문제를 해결하기 위해 필요한 세부적인 설계 방법(기본 지침)인 셈.
• 예를 들어 클라이언트-서버 아키텍처와 같은 특정 스타일을 사용한다면 다음과 같은 방법론을 구비하는 것.
  => '클라이언트-서버 아키텍처에서 계층을 x 개 가지게 하자.'
• 코드 기반(code base)에 광범위한 영향을 미치며, 가장 빈번하게 전체 응용 프로그램에 수평적(ie.계층 내부의 코드를 구조화하는 방법) 혹은 수직적(ie. 요청이 외부 계층에서 내부 계층 및 후면으로 처리되는 방법)으로 영향을 미침.
• 예시 ↓
  -Three-tier
  -Microkernel
  -Model-View-Controller
  -Model-View-ViewModel

디자인 패턴

• 구축 단계에서 제공, 실질적 구현.
• 디자인 패턴은 범위(scope)가 아키텍처 패턴과 달라, 코드 베이스에 미치는 영향이 적고, 코드 베이스의 특정 섹션에 협소하게 영향을 줌.
• 즉, 특정 구성요소 구현과 관련된 세부 사항이라 할 수 있음.
• 예시 ↓
  -런 타임에 인스턴스화해야 할 타입만 알고 있을 때 개체를 인스턴스화하는 방법.
  -개체가 상태에 따라 다르게 동작하도록 하는 방법.

결론

• 결국 모두 scope가 관건인셈.
• 아키텍처 스타일은 최상위 추상화 단계에서의 앱 디자인.
• 아키텍처 패턴은 아키텍처 스타일을 구현하는 방법.
• 디자인 패턴은 구현 단계에서 발생하는 문제에 대한 해결 방법.
• 특정 프로젝트에서 사용하는 scope에 따라 패턴을 아키텍처 패턴 또는 디자인 패턴으로 사용할 수도 있음.

Architectural Styles vs. Architectural Patterns vs. Design Patterns