[Flutter] 클린 아키텍처 리펙토링 (4) - 계층 별 파일 간 의존성 분리

ㅤ

처음에 클린 아키텍처를 프로젝트에 반영하려고 하면서 어떻게 구조를 설계해야하나 고민을 할 때, 아래같은 내용을 담은 적이 있었다. 그리고, 이게 다시 한 번 불편하다고 느낀 상황이 와버렸다! ㅋㅋㅋ

ㅤ

아래 이미지처럼 import 문의 크기를 줄이기 위해 열심히 GBDF를 적용해 간소화를 적용하고 있었다.

ㅤ

그런데, 저렇게 줄이고 나니깐 각 파일에서 어떤 계층을 참고하고 있는지 더 선명하게 보이기 시작했다. 다시 말하자면, domain 모델에서도 data 계층의 파일들을 import 하여 사용하고 있는게 더 눈에 잘 띄기 시작했다.

ㅤ

물론 이게 riverpod 방식으로 파일 구조를 짜려다보니, 앞서 올린 고민 이미지에서 그린 것 처럼 domain에서 data에서 작성한 파일을 필연적으로 import하여 사용할 수 밖에 없는 것 같았다. 그렇게 작성한 코드가 아래의 형식이다. 왼쪽을 보면 domain 에 포함되어있는 usecase 파일에서 data 계층의 repository provider를 import 하여 사용하고 있는 것을 확인할 수 있다.

ㅤ

찾아보니, 요런 문제를 해결하기 위해 플러터의 Injection 패키지를 사용하기도 하던데, riverpod과 섞이면 오히려 더 복잡해질 것 같아서 riverpod을 사용한 여러 예제들을 찾아헤맸다.

ㅤ

그리고 아래 레포지토리를 찾았다. 완전 우리랑 적합하거나 동일한 구조는 아니였지만, 충분히 참고할 만한 자료라고 판단했다. 이 레포에서는 provider로 전역에 뿌려주는 코드는 파일과 폴더 자체를 class 파일과 분리해서 관리하고 있었다.

https://github.com/FabianVarela/crud_todo_app

GitHub - FabianVarela/crud_todo_app: Create a To-do List Flutter app managing CRUD with Firebase, using RiverPod as state manage

ㅤ

이 방식을 고민해봤을 때, 2가지 장점이 있다고 판단하였다.

1. 우선 domain 계층에서 data 계층을 사용하는 쪽은 provider로 의존성을 주입하는 부분임. 즉, 계층간의 로직에서는 아키텍처를 위반하지 않음. 따라서, 의존성을 주입하는 부분을 다른 파일로 이동한다면 ‘계층 참조 규칙’을 준수하도록 코드를 작성하였음을 명확하게 코드로 표현할 수 있음.
2. 클린 아키텍처와 이를 구현하기 위해 사용한 도구인 riverpod은 사실상 별개임. 아키텍처 로직과 provider를 통한 의존성 주입 코드를 분리하여, 실질적인 아키텍처 내 로직 파일과 riverpod 코드를 분리할 수 있음.

ㅤ

이에 dependency 파일을 분리해주었다. provider 쪽에도 어떻게보면 계층이 구분되어 있기 때문에, 이에 맞춰 파일을 분리해 presentation에서 data 계층을 사용하는 등의 이상한 코드를 방지하고자 했다. 그 결과 아래처럼 코드를 정리할 수 있었다.

ㅤ

위 이미지에서 볼 수 있듯이, 아키텍처 내 비즈니스 로직(Usecase) 파일에는 riverpod 코드가 제거되어 순수 로직만 남게 되었고, data 계층의 파일을 import 하지 않아 아키텍처의 계층간의 참조 방향도 준수할 수 있게 되었다.

ㅤ

provider만 모아둔 dependency 파일에는 이렇게 provider 쪽에 해당하는 코드만 모여있게 되었고, 아키텍처에 해당하는 계층, 코드와 provider 영역을 분리하여 훨씬 자연스러운 코드로 만들어졌다고 생각된다.

ㅤ

아마도 불편한 점은 클래스 작성 후 provider로 뿌려줄 때 파일이 분리되어있다는 점인데, 요 부분 빼고 나머지는 장점뿐인 구조가 아닐까 싶다.

ㅤ

---

해당 수정에 대한 PR은 여기 !

https://github.com/cau-bootcamp/wehavit/pull/192

[#191] refactor: provider 정리 by sm-amoled · Pull Request #192 · cau-bootcamp/wehavit