초기 설계 단계에서 UI, 상태 관리, 비즈니스 로직, 네트워크 로직을 명확히 분리하는 것을 가장 중요한 목표로 설정했습니다.

• MVVM
  • View (Screen): UI 렌더링과 사용자 이벤트 전달만 담당
  • ViewModel: UI 상태(State) 관리 및 사용자 액션 처리
  • Model: 도메인 데이터 구조
• Repository 패턴
  • API / Local DataSource 분리 가능
  • ViewModel이 네트워크 구현(Dio)에 직접 의존하지 않도록 설계
  • 추후 테스트 및 유지보수 용이성 확보

MVVM을 선택한 이유

• Flutter에서는 Widget이 쉽게 비대해질 수 있기 때문에,

  → ViewModel을 통해 상태와 로직을 분리하는 것이 필수적이라고 판단했습니다.

결과적으로 View는 “어떻게 보여줄지” 에만 집중하고,

ViewModel은 “어떤 상태를 만들지” 를 책임하도록 설계했습니다.

Repository 패턴을 함께 사용한 이유

• ViewModel이 API(Dio), 로컬 저장소(SecureStorage) 에 직접 의존하지 않도록 하기 위해 사용했습니다.
• 추후 데이터 소스가 변경되더라도 ViewModel 로직에 미치는 영향을 최소화하기 위해 해당 패턴을 적용했습니다.

UseCase를 사용하지 않은 이유

Clean Architecture 관점에서 UseCase 레이어의 필요성도 충분히 인지하고 있었지만,

이번 과제에서는 의도적으로 UseCase 레이어를 두지 않았습니다.

이번 과제의 비즈니스 로직은 비교적 복잡한 규칙을 가지는 경우가 많지 않다고 판단했으며,

이러한 상황에서 UseCase를 추가하는 것은 오히려 다음과 같은 문제를 야기할 수 있다고 생각했습니다.

• 단순한 로직에 비해 파일 및 레이어 수만 증가