폴더 구조를 계속 변경하는중... ~ing

앱의 폴더구조란, 앱이 어떤 아키텍쳐 혹은 디자인 패턴을 표방하고 있는지 가장 잘 볼 수 있는 곳이라고 생각한다. 처음에 내 폴더 구조는 이랬다.

앱 폴더 구조

lib/
│
├── core/                     # 비즈니스 로직, 데이터 관리
│   ├── models/               # 데이터 모델 클래스들
│   ├── services/             # 외부 API, 데이터베이스 서비스
│
├── ui/                       # 화면 관련 코드
│   ├── view/                 # 화면 UI 구성
│   ├── widgets/              # 공통으로 사용하는 위젯
│   ├── viewModel/            # UI와 비즈니스 로직을 연결함 
│      
│
├── di/                       # 의존성 주입 (Dependency Injection) 설정
│   ├── di.dart
│
└── main.dart                 # 앱의 진입점

• core/: 데이터 모델과 외부 서비스 로직을 포함한 비즈니스 로직 관련 폴더.
• ui/: UI 관련 코드 (화면, 위젯).
• viewmodels/: UI와 로직을 연결하는 ViewModel 파일들.
• di/: 의존성 주입 관련 설정 파일.

근데, 아무리 봐도 UI에 viewModel이 있는것이 조금 이상하며(아니 뷰가 아니라 뷰랑 비즈니스로직을 연결해주는 곳,, 아닌가? 싶어져서) , 서비스라고 하는 곳이 사실은 다 데이터 통신을 하는 곳이라 service가 적절한지에 대해 네이밍을 고민하게 되었다. 그래서

앱 폴더 구조

lib/
│
├── core/                     # 비즈니스 로직, 데이터 관리
│   ├── models/               # 데이터 모델 클래스들
│   ├── repositories/         # 데이터 저장소, 외부 API 통신
│
├── ui/                       # 화면 관련 코드
│   ├── view/                 # 화면 UI 구성
│   ├── widgets/              # 공통으로 사용하는 위젯
│
├── viewmodels/               # ViewModel (UI와 로직을 연결)
│
├── di/                       # 의존성 주입 (Dependency Injection) 설정
│   ├── di.dart
│
└── main.dart                 # 앱의 진입점

이렇게 바꿨는데...
core라는 네이밍이 또 문득 어색해진것이다, 지금 성격엔 domain이란 네이밍이 더 맞지 않나? 왜냐하면 여기는 지금 핵심 비즈니스 로직과 데이터 모델을 포함한 부분이잖아.. 그리고 같은 레벨에 viewmodel이 있는게 맞나? 하는 고민이 들었다

수정된 앱 폴더 구조

lib/
│
├── domain/                   # 비즈니스 로직 및 데이터 모델
│   ├── models/               # 앱의 데이터 구조를 정의한 모델 클래스
│   ├── repositories/         # 데이터 처리 및 외부 API, DB 통신 로직
│
├── presentation/             # UI와 관련된 모든 코드
│   ├── views/                # 각 화면 구성 파일
│   ├── widgets/              # 재사용 가능한 공통 위젯
│
├── application/              # 상태 관리와 UI 비즈니스 로직 연결
│   ├── viewmodels/           # 상태 관리 및 로직
│
├── di/                       # 의존성 주입 (Dependency Injection) 설정
│   ├── di.dart
│
└── main.dart                 # 앱의 시작점 (메인 진입 파일)

그래서 이 형태가 최종이 되었는데, API를 데려오고 통신하는 일이 생기면 사실 Data 레이어를 또 만들어야하나 고민이 되고,,
결국은 클린 아키텍쳐의 형태에 비슷해졌다는 생각이 드는,,,날이었다,, 고민많이해봐야겠다

 

 

최종

lib/
│
├── domain/                      # 비즈니스 로직과 모델 정의
│   ├── models/                  # 모델 정의
│   ├── repositories/            # 레포지토리 인터페이스
│   └── usecases/                # 비즈니스 로직 유즈케이스
│
├── data/                        # 데이터 관련 레이어
│   ├── datasources/             # API/Firebase 등 데이터 소스
│   ├── repositories/            # 레포지토리 구현체
│   └── services/                # WebRTC 등 기타 서비스
│
├── presentation/                # UI 관련 레이어
│   ├── views/                   # UI 화면
│   ├── viewmodels/              # 상태 관리 (ViewModel)
│   └── widgets/                 # 재사용 가능한 위젯
│
├── di/                          # 의존성 주입 설정
│   └── di.dart
│
└── main.dart                    # 앱 진입점

결국엔  뷰모델을 프레젠테이션 안으로 넣었다. 
MVVM에서 뷰모델은 프레젠테이션 레이어의 핵심으로, View와 직접적인 상호작용을 하므로 ViewModel이 여기에 속하는 것이 자연스럽다.

---

 

댓글은 언제나 환영합니다 의견 나눠 주세요😀