Everything is Trade-Offs Everything is Trade-Offs

레포지토리 패턴으로 구성된 리버팟 아키텍처로 프로젝트를 진행하다가 크게 아키텍처 구조를 갈아엎은 적이 있었다. 이유는 어떤 특정한 기준으로 아키텍처 구조를 잡았다가 볼륨이 커지면서 레어어간의 질서를 깨뜨리는 도메인들이 등장했기 때문이었다. 개발자라면 한 번쯤 깊게 고민해 봤을 법한 주제인 거 같아 실제 프로젝트를 하면서 느꼈던 것들을 글로 남겨보려고 한다. "해당 글의 내용은 프로젝트는 레포지토리 패턴으로 구성된 리버팟 아키텍처를 배경으로 하고 있습니다. 특정 아키텍처 패턴에 종속된 주제는 아니지만 리버팟 아키텍처에 대해 배경지식이 필요하다면 아래 글을 참고해 주세요" [Flutter] Repository pattern + Riverpod feat.안드레아 로그인 회원가입 등 구현에 대해 이야기하기 ..

이전 글에선 Data-Layer와 Domain-Layer를 실제 코드와 함께 정리했었습니다. 데이터 레이어와 도메인 레이어는 대부분 api 통신에 관한 코드들로 구성되어 있었습니다. 이번 글에서는 클라이언트단의 비즈니스 로직들을 다루는 Application-Layer 부분을 다뤄보겠습니다. 제 프로젝트를 기반으로 설명하는 거라 아키텍처와 무관한 내용이 포함될 수 있습니다. ❗️주의: 스스로 학습하며 구성한 프로젝트라 현직자 분들이 보시면 이상하게 느끼 실수 있습니다. "쟤는 저런 식으로 해봤구나" 정도로만 봐주시고 만약 틀린 부분을 발견하셨다면 피드백 남겨주시면 감사하겠습니다 해당 글은 이전 글에서 계속 이어집니다. 이해가 필요하신 분은 아래의 글을 참고해 주세요! [Flutter] 실제 Reposit..