[패턴] 자주 사용되는 아키텍처패턴 4가지

1. 레이어 패턴(Layer Pattern)

가장 흔히 사용되는 패턴으로 시스템을 계층화하고 하위 레이어가 제공하는 기능을 상위 레이어가 이용함으로써

각 레이어의 구조를 단순화한다는 발상에서 시작된다.

각 레이어는 해당 레이어가 의존하는 직접적인 하위 레이어만 알면 된다.

 - 장점

하나의 모듈을 업데이트 할때 다른 모듈이 받는 영향을 최소화

각 레이어의 책임을 명확히 할 수 있음

 - 레이어 구조

 - 3계층

프리젠테이션 레이어

응용프로그램에서 사용자와 상호작용하는 인터페이스(UI)로 데이터를 표시하고 서버와의 통신을 처리하는 계층

어플리케이션 레이어

사용자와 상호작용하면서 수집된 데이터를 처리하고 API를 통해 데이터레이어와 통신하는 계층

데이터 레이어

어플리케이션 레이어에서 처리된 데이터를 저장하고 관리하는 계층

- 4계층

애플리케이션 레이어를 비즈니스 레이어와 퍼시스턴스 레이어로 세분화 한다.

비즈니스  레이어 

핵심 로직 구현, 데이터 적합성 검증 등을 처리하는 계층

퍼시스턴스 레이어

데이터 처리를 담당하는 계층

- 사용 규칙

모듈은 반드시 하나의 레이어에만 존재해야 한다.

상위 레이어는 하위 레이어를 이용 가능해야 한다. (방향은 한방향으로 흘러야 한다.)

2. 브로커 패턴(Broker Pattern)

외부에 분산된 컴포넌트를 호출하려고 할때 클라이언트 요청 값을 분석하여 서버 컴포넌트에 전달하고

그 결과값을 전달하는 역할을 하는 스타일이다.

클라이언트와 서버 사이의 브로커라는 컴포넌트를 두어

보다 효과적으로 서버와 클라이언트 사이를 분리할 수 있어 분산 시스템을 구축하는데 용이하다.

따라서 분산 시스템이나 RPC를 구현할때 사용되는 패턴

 - 구조

 - 장점

컴포넌트간의 위치 투명성을 제공

플랫폼 간의 Portability 제공

서버 다른 시스템의 연동을 용이하게 한다.

재사용 컴포넌트 확보에 용이

 - 단점

성능에 대한 불이익

장애 대처율이 떨어짐

테스트 디버깅의 복잡함

 - 설계 순서

 1. 객체 모델을 정의하거나 기존 모델을 재사용 할  지 결정

 2. 컴포넌트들 사이의 상호 연동을 어떤 방식으로 할 지 결정

 3. 클라이언트와 서버간의 협력을 위한 Broker 컴포넌트의 역할 정의

 4. Proxy 객체를 사용해 환경과 관련된 부분 캡슐화 설계

 5. Broker 컴포넌트 설계

 6. IDL 컴파일러 설계

3. MVC패턴

모델, 뷰, 컨트롤 세개의 컴포넌트로 애플리케이션을 구분한 패턴

 - 구조

출처 : MDN

 - 모델

모델은 앱이 포함해야할 데이터가 무엇인지를 정의한다.

데이터의 상태가 변경되면 모델을 일반적으로 뷰에게 알리며 컨트롤러에게 알리기도 한다.

 - 뷰

뷰는 앱의 데이터를 보여주는 방식을 정의한다.

 - 컨트롤러

컨트롤러는 앱의 사용자로부터의 입력에 대한 응답으로 모델 또는 뷰를 업데이트하는 로직을 포함한다.

 - 장점

비즈니스 로직과 UI로직을 분리하여 유지보수를 독립적으로 수행가능

Model과 View가 다른 컴포넌트들에 종속되지 않아 애플리케이션의 확장성, 유연성에 유리함

중복 코딩의 문제점 제거

 - 단점

컨트롤러에 다수의 모델과 뷰가 복잡하게 연결되어 있는 상황이 발생할 수 있음

 - 사용규칙

  모델

사용자가 편집하길 원하는 데이터를 가지고 있어야 한다.

뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야 한다.

변경이 일어나면 변경 통지에 대한 처리방법을 구현해야 한다.

 뷰

모델이 가지고 있는 정보를 따로 저장해서는 안된다.

모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야 한다.

변경이 일어나면 변경통지에 대한 처리방법을 구현해야 한다.

 컨트롤러

모델이나 뷰에 대해서 알고 있어야 한다.

모델이나 뷰의 변경을 모니터링 해야 한다.

4. 상태 패턴(State Pattern)

상태 패턴은 객체의 내부 상태가 변경될때 해당 객체가 그의 행동을 변경할 수 있도록 하는 행동 디자인 패턴이다.

객체가 행동을 변경할때 객체가 클래스를 변경한 것처럼 보일수 있다.

 - 예시

로그인상태, 비로그인상태

홈페이지에서 로그인 상태인 경우 물건을 구매할수 있게 설정했다.

비로그인 상태에서 물건을 구매한다면 로그인을 하는 페이지로 가도록 설정했다.

이처럼 로그인상태여부를 확인하여 다른 행동이 나오게 할수 있다.

 - 구조

 - 장점

특정 상태들과 관련된 코드를 별도의 클래스로 구성하여 단일 책임 원칙이다.

기존 상태 클래스틀 또는 컨텍스트를 변경하지 않고 새로운 상태에 도입할수 있다.

거대한 상태 머신 조건문들을 제거하여 컨텍스트의 코드를 단순화 한다.

 - 단점

상태 머신에 몇가지 상태만 있거나 머신이 거의 변경되지 않을때 상태 패턴은 과도할 수 있다.

 

참조

https://velog.io/@formin/%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%ED%8C%A8%ED%84%B4Architecture-Patterns-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4Design-Pattern

https://carrotweb.tistory.com/215

https://cocoon1787.tistory.com/733

https://refactoring.guru/ko/design-patterns/state