DAY 11-1 | Flutter App architecture (1) 아키텍처 개념
Flutter 공식문서를 따라 Flutter App architecture를 살펴보자.
In this guide, 'architecture' refers to how to structure, organize, and design your Flutter app in order to scale as your project requirements and team grow.
이 가이드에서 '아키텍처'는 프로젝트 요구사항이 늘어나고 팀이 성장함에 따라 Flutter 앱을 구조화하고 조직화하며 설계하는 방법을 의미한다.
좋은 아키텍처가 주는 이점은 다음과 같다.
- Maintainability (유지보수성)
아키텍처는 시간이 지남에 따라 발생할 수 있는 수정, 업데이트 및 문제 해결을 한층 수월하게 만든다.- Scalability (확장성)
애플리케이션을 면밀하게 설계하면 많은 사람들이 동시에 동일 코드베이스에 기여하더라도 코드 충돌을 최소화할 수 있다.- Testability (테스트 용이성)
아키텍처를 의도적으로 설계한 애플리케이션은 대개 입출력이 명확하고 클래스가 단순하여 모킹 및 테스트를 수행하기 수월하다.- Lower cognitive load (인지 부하 감소)
코드를 이해하기 쉽게 작성하면 프로젝트에 새로 합류한 개발자가 더 빠르게 생산성을 발휘할 수 있으며, 전반적인 코드 리뷰 시간도 단축된다.- A better user experience (향상된 사용자 경험)
기능을 더 빠르게 출시할 수 있고 발생하는 버그도 감소한다.
일반적인 아키텍처 개념
Flutter의 아키텍처와 관련된 일반적인 개념들을 몇 가지 살펴보자.
Separation of concerns | 관심사 분리
애플리케이션의 기능을 독립적이고 자체 포함된 단위로 나누어 모듈성과 유지보수성을 높이는 앱 개발의 핵심 원칙
- 거시적 관점에서 보면 UI 로직과 비즈니스 로직을 분리하는 것
→ 계층형 아키텍처(Layered architecture)- Flutter에서는 이에 따라 로직을 최대한 덜어낸, 가볍고 재사용 가능한 UI widget을 작성한다.
Dijkstra에 의하면 다양한 측면들을 한꺼번에 해결하려고 덤벼들면 얻을 수 있는 것은 아무것도 없으며, 오히려 역효과만 난다. 따라서 지금 들여다보고 있는 관점에서는 다른 측면이 당장 고려 대상이 아니라는 사실을 명확히 인정하고, 하나의 트랙에 집중하면서도 동시에 여러 트랙을 의식하는 영리한 사고방식이 필요하다.
Layered architecture | 계층형 아키텍처
애플리케이션을 각각의 명확한 역할과 책임을 가진 독립된 계층으로 조직화하는 소프트웨어 디자인 패턴
직접 맞닿아 있지 않은 레이어는 서로 소통하기는 커녕 서로의 존재조차 알지 못하는 구조
- UI 레이어
데이터를 사용자에게 화면으로 보여주고 사용자의 상호작용을 처리하는 레이어- 로직 레이어
핵심 비즈니스 로직을 구현하며 데이터 레이어와 UI 레이어의 상호작용을 중재하는 레이어
(단순히 사용자에게 데이터를 보여주고 그 데이터를 수정하는 기능만 제공하는 경우 생략되기도 한다.)- 데이터 레이어
데이터 소스와의 상호작용을 관리하며 비즈니스 로직 레이어에서 사용할 수 있도록 데이터를 외부에 노출하는 레이어
서로 직접적으로 닿아 있지 않은 영역이 서로의 영향을 받지 않도록 하는 게 핵심이다. 역할과 책임이 명확하여 독립적인 개발 및 테스트가 가능하고, 어느 레이어에 대한 코드 수정이 다른 레이어에 영향을 주지 않아 유지보수성이 좋다.
Single source of truth; SSOT | 단일 진실 공급원
모든 데이터와 정보가 오직 하나의 신뢰할 수 있는 출처에서 생성 및 수정되도록 조직하는 방식
일반적으로 데이터 레이어의 일부인Repositoryclass가 담당하며, 각 data type마다 하나의Repositoryclass가 매칭된다.
SSOT는 Rust로 작성된 엔진과 Python(FastAPI) 게이트웨이 간의 통신에 gRPC를 사용할 때 살펴봤던 개념이다. 데이터 무결성 및 일관성 측면에서 중요하다. 이를 통해 데이터 불일치에 대한 불필요한 휴먼 에러를 사전에 차단할 수 있다.
Unidirectional data flow; UDF | 단방향 데이터 흐름
이벤트는 UI 레이어에서 시작하여 로직 레이어를 거쳐 데이터 레이어 방향으로 흐른다. 상태는 반대로, 데이터 레이어에서 시작하여 로직 레이어를 거쳐 UI 레이어 방향으로 흐른다.
때로는 사용자 상호작용 없이 데이터 레이어에서 먼저 흐름이 시작되기도 한다. 어찌 되었건 데이터 변경은 데이터 레이어의 SSOT에서만 수행된다.
UI는 (immutable) state의 function이다
Flutter는 선언형 UI로, 데이터가 UI를 주도한다.
state가 달라지면 rebuild를 트리거하고 UI를 새로 그려 state를 반영한다.
Extensibility | 확장성
아키텍처의 각 구성 요소는 잘 정의된 입력과 출력 목록을 가져야 한다.
clean interface를 사용하여 기존 코드를 수정하지 않고도 class의 구체적인 구현체를 언제든지 자유롭게 교체할 수 있어야 한다.
Testability | 테스트 용이성
소프트웨어의 확장성을 높여주는 원칙들은 테스트를 용이하게 만드는 데도 기여한다.
구체적인 구현체를 자유롭게 교체할 수 있는 만큼 쉽게 모킹하여 테스트할 수 있는 것이다.
