Smart/Dumb 구분을 넘어 Business Rule을 격리한 FE 아키텍처 설계

Clean Architecture on the Frontend: Beyond Smart and Dumb Components

djblackett2026년 6월 7일21분intermediate

AI 요약

Context

Container/Presentational 패턴 기반의 Smart/Dumb 컴포넌트 구조를 채택했으나 비즈니스 규칙이 컴포넌트 내부에 산재하는 문제 발생. UI 렌더링 로직과 애플리케이션의 핵심 도메인 규칙이 결합되어 유지보수성과 재사용성이 저하된 상태를 분석함.

의사결정 성격에 따른 관심사 분리: Business Meaning, Application Workflow, UI Interaction, Framework Orchestration의 4가지 계층으로 구분
Domain Layer 추출: canMarkInvoicePaid(invoice)와 같이 UI 프레임워크 의존성 없는 순수 TypeScript 함수로 비즈니스 규칙 정의
Application Layer 구축: markInvoicePaid(invoiceId, repository)를 통해 도메인 규칙과 인프라스트럭처를 연결하는 워크플로우 제어
Presentation Layer 단순화: 컴포넌트는 상태 반영 및 이벤트 전달에 집중하며 Toast, Cache, Focus 관리 등 UI 메커니즘만 처리
프레임워크 테스트(Framework Test) 적용: UI 프레임워크 변경 시에도 유효한 로직을 식별하여 Domain 계층으로 이동
임포트 스멜 테스트(Import Smell Test) 수행: useMutation, toast 등 UI 라이브러리 임포트 여부로 Presentation 로직 판별

실천 포인트

1. 현재 컴포넌트 내 비즈니스 규칙이 클릭 핸들러나 useEffect 내부에 하드코딩되어 있는지 확인

2. 해당 로직을 순수 TypeScript 함수로 추출했을 때 UI 라이브러리 없이 단위 테스트가 가능한지 검증

3. 프레임워크 의존성(Hooks, Context)이 없는 로직은 Domain/Application 계층으로 격리

4. UI 상태 관리(Focus, Toast)와 비즈니스 유효성 검사 로직을 서로 다른 함수로 분리하여 관리

태그