[Architecture] Design Pattern

디자인 패턴

어플리케이션 설계에서 자주 발생하는 (되풀이되는) 문제에 대한 모범 답안 혹은 공략집.

사용 이유

1. 검증된 해결책
   이미 검증된 방식으로 구현된 구조를 활용하여 생산성을 높히고 효과적으로 해결방안을 찾음
2. 효율적인 소통 방식
   복잡도가 높아지는 상황에서 사전에 약속해 둔 용어들로 표현하여 효율을 높힘.
3. 유지보수 용이
   각각의 기능을 담당하는 영역을 분리하여 관리하기 쉽도록 설계함.

종류

1. MVC (Model- View- Controller)

• Model: 정보, 데이터를 관리하는 역할 (React에서 state)

• View: 브라우저 화면, 사용자 인터페이스 요소를 담당 (React에서 JSX)

• Controller: 사용자의 Action에 의해 이벤트를 감지하고 처리하는 역할 (Model 또는 View를 업데이트하는 로직을 포함)

• 양방향 데이터 흐름 (Bidirectional data flow)
  사용자에 의한 Action이 일어나면, Controller가 감지해 Model에게 데이터를 바꾸라고 요청하고, 바뀐 데이터는 View에 반영 된다.
  또한 View에서 Model을 이용해 업데이트 할 수 있고, 바뀐 모델로 또 다른 View가 업데이트 될 수 있다.

• 관심사의 분리(Separation of Concern, SoC): 각 부분별로 역할이 분명하여, 한 파일에서 의존도를 낮게 관리한다.

• MVC 패턴의 한계: 프로젝트의 단위가 커지면, Model과 View가 자연스럽게 늘어나고, model과 view의 의존도가 높아지면서 업데이트를 예측하기 어려워 진다.

2. Flux

• Action: 이벤트를 구독하고 있다가 이벤트 발생 시 Action 객체를 만들어서 Dispatcher에 전달하는 역할을 하는 Action Creator

• Dispatcher: Action 객체의 type property에 따라 Store에 어떤 행동을 할지 결정, Store의 콜백을 등록하고, Action을 Store에 배분해준다. (Flux의 중앙 허브역할)

• Store: 상태를 저장하는 저장소의 역할, 상태를 변화시키는 로직을 갖고 있음

• View: Store의 상태에 따라 화면에 그려지는 부분

• 단방향 데이터 흐름 (Unidirectional data flow)
  이벤트가 발생하면, Dispatcher에게 생성된 Action객체를 전달한다. Action 객체를 전달받은 Dispatcher에서 Action객체의 type property에 따라 Store의 상태를 업데이트하고, View는 업데이트 된 State에 따라 화면에 그려진다.

• 마지막 View에서 화면이 렌더링 되면 View에서 새로운 Action 객체를 만들어 시스템에 전파해 업데이트 된 내역을 알게 한다. 결국 데이터는 한쪽 방향으로만 흐르게 되고, 각각의 구조는 서로 의존하지않고 있어서 데이터 구조파악과 흐름을 예측하고 오류를 찾아가기 수월하다.