2025-11-26
개발자로서 클린아키텍처를 알고 사고할 때랑, 모르고 사고할때 유지보수성은 크게 차이난다.
큰 규모의 프로젝트와 팀 협업에 용이.
유지보수성 UP
- 유지보수비용 > 개발 비용
- 유지보수가 용이한 구조가 중요
- 사람마다 코딩패턴이 달라서, 새로운 사람이 와도 동일한 구조로 개발할수있도록 구조의 표준화
의존성 관리
- 의존성이 뒤엉키면 기술 스택 바꾸기가 어려움
- 기술이 바뀌어도 도메인 로직은 절대 깨지지않는 형태의 구조가 필요
오래가는 것과 자주 바뀌는걸 분리
- UI와 데이터 출처는 자주 바뀜 (UI, Data)
- 비즈니스 규칙은 가장 오래 살아남음 (Domain)
안쪽은 바깥쪽을 모른다.
- 유지보수하기가 쉬워짐
- 예를들어 UI만 바뀌면, VM은 수정할 일 없도록 설계 해야함
리펙토링 지옥에 빠지지 말자!
- 일단 만들어놓고 나중에 고친다 → 절대 쉽지않음.
- 잘못된 구조가 커지면 수정 난이도가 매우 높다.
구조가 처음부터 완벽할 필요는 없다
- 다만, 확장 가능한 형태로 만드는게 중요!!!
- (Domain이 필요없으면 처음에는 없어도되고 필요하면 만들면 됨)
의존성을 인터페이스로 통제한다.
- Domain은 Repository의 인터페이스만 알고있음
- Domain은
데이터를 어떻게 가져오는가를 모름
왜 이렇게 하는가?
API 방식등 데이터 소스가 바껴도 도메인을 건드릴 필요없음
어차피 인터페이스를 통해 연결되있기 떄문에, Repository만 수정하면 됨.
도메인 레이어
- 재사용성이 가장높은 레이어
- 비즈니스 규칙이 위치하는 위치
- 순수 Dart 모델 / Usecase / Repo 인터페이스로 구성
- 도메인 레이어에 위치한 모델의 경우, 외부기술(파이어베이스, 리버팟, 플러터)을 알면 안됨. 순수 dart코드만 포함
유즈케이스
- Repo에는 데이터의 입출력등, 저장소에 부합하는 작업만 다룬다
- vm도 호출과 반환 위주로 간단하게 구성한다
- 검증로직이나 큰 볼륨의 로직들이 병행되어야할경우 여기서 다룬다
- 또한 하나의 기능에서 다수의 repo가 필요한 경우 도메인 레이어에 들어가게됨