Coderifleman's blog

frontend development stories.

플럭스 아키텍처에서 스토어란 무엇인가?

플럭스 아키텍처를 이용해 애플리케이션을 개발할 때 가장 먼저 스토어를 설계한다. 그 이유는 스토어가 무엇보다 중요한 데이터를 관리하는 객체라고 해석하기 때문이다.

스토어는 모델이나 엔티티 등의 데이터를 관리하기 위한 공간이 아니다. 그저 표현을 위한 상태를 관리하는 객체일 뿐이다. 예를 들어 데이터를 필터링하기 위한 기준값이 있다고 하자. 이 값이 스토어에 존재한다고 해서 실제 필터링에 사용되지 않는다. 스토어에 존재하는 이유는 이 값을 어딘가에 표현해야 하기 때문이다.

표현 계층은 표현을 위한 상태가 필요하다. 그리고 애플리케이션 비즈니스는 필연적으로 도메인 데이터가 필요하다. 만약 두 가지의 책임을 스토어가 갖게 된다면 애플리케이션 내에서 무엇보다 중요한 거대한 객체가 탄생하게 된다.

스토어의 의존 관계
<그림 1. 스토어의 의존 관계>

첫 번째 다이어그램을 보자. 스토어에서 표현을 위한 상태와 도메인 데이터를 모두 관리하고 있다. 이 경우 표현 계층과 애플리케이션 비즈니스 계층 모두 스토어를 의존한다. 애플리케이션 비즈니스는 도메인 데이터에 접근할 수 있어야 하므로 스토어에 겟터(Getter) 메서드도 작성해야 한다.

반면 두 번째 다이어그램에서는 데이터의 관리 책임을 분리했다. 자연스럽게 의존 관계는 좌측에서 우측으로 이뤄진다. 스토어에서 겟터를 제공할 필요도 없다. 데이터를 관리하는 계층에서 적절한 수단을 제공하면 된다. 스토어는 상대적으로 단순하고 각 계층을 테스트하기도 쉽다.

플럭스 아키텍처 의존 관계
<그림 2. 플럭스 아키텍처 의존 관계>

필자는 스토어를 표현 계층의 한 요소로 해석한다. 스토어에서 도메인 데이터를 분리해야만 클린 아키텍처에서 말하는 의존 규칙을 지킬 수 있다.

플럭스 아키텍처를 이용해 애플리케이션을 설계하더라도 모델 계층은 언제나 필요하다. 즉, 애플리케이션을 개발할 때 가장 먼저 시작해야 할 지점은 스토어가 아니라 바로 모델이다.