[Flutter] 클린 아키텍처 리펙토링 (2) - Data Layer

열심히 프로젝트 구조를 클린 아키텍처 구조로 개선하고 있다. 내가 싼 똥이 점점 정리되는 중이라고 느껴진다. 뭔가 다시 작업을 시작하면 더 깔끔하고 편리하게 작업을 진행할 수 있을 것 같은 느낌이랄까…? ㅋㅋㅋㅋ

ㅤ

그래도 나름의 고민을 거듭하면서 구조를 개선해나가고 있는 중이다. 이번 차례에는 Data Layer에 대한 대공사를 진행하고 있는데, repository - repository impl - datasource 의 관계를 어떻게 구성하는게 적절한 지에 대해 고민을 열심히 하고 있다.

ㅤ

(대충 뭔가 호작질중)

ㅤ

그렇게 설계한 2번째 구조는 아래와 같다.

ㅤ

먼저 repository와 repository impl은 1대1 관계로 작성해주었다. 각 repository는 interface로서 구현이 필요한 함수들의 명세를 가지고 있고, 이를 각 repository impl에서 구현해준다. 여기에서 repository의 구현에 필요한 데이터 작업을 처리하기 위해서 Datasource를 사용해주어야 한다. 각각의 repository는 Datasource를 필요에 따라 0개 ~ 2개 이상을 참조하여 사용할 수 있다. (그치만, 요녀석은 적을수록 좋은 것 같다)

ㅤ

나의 경우에는 일반적인 앱 기능의 동작에 필요한 함수들은 하나의 datasource에서 관리하도록 만들어뒀다. 그러나, 위 구조 이미지에서 4번째 행에 해당하는 것처럼, 2개의 datasource를 사용하는 녀석이 있다. 로그인 기능에서 구글 계정을 사용한 로그인, 애플 계정을 사용한 로그인, 서비스 자체 계정을 사용한 로그인 등의 여러 source가 필요하다. 이에 따라 각 기능을 여러 datasource를 통해 개별적으로 구현하고자 하였다. (생각해보니, 조금 더 정리하면 모든 로그인이 동일한 로그인, 로그아웃, 계정생성 등을 사용할 수 있으니, 하나의 Datasource를 만들어두고 datasource impl만 다르게 만들어서 여럿 적용하도록 구조를 개선해도 될 것 같다.)

ㅤ

Datasource는 단순 interface이고, 이를 구현한 Datasource Impl 을 작성해주면 된다. 여기에서 기존 서비스는 파이어베이스로 작성하였기 때문에 firebase_datasource_impl 클래스를 구현해주고 있다. 테스트용 데이터를 담고 보여주는 mockup_datasource_impl 을 작성해서 firebase_datasource_impl 를 대치하는 방식으로 클린 아키텍처 구조의 장점을 한 번 느껴보려고 한다. 단순히 어떤 datasource를 적용할 지 선택할 수 있게 스위치를 만들어서 적용하게 만들면 짜릿하지 않을까? ㅋㅋㅋㅋ 그치만 여기까지 갈 수 있을지는… 열심히 개발해봐야지…

ㅤ

개선하면서 느낀 점은 기존에 코드를 막 적어둔 경우가 꽤나 많았다는 점이다. 내가 알고있는 설계에 따르면 datastore를 수정 → repository 쪽에만 수정이 필요해야 하는데, 갑자기 뷰에서 빨간줄이 떠버리는 경우가 있었다. 아무래도 일정에 치여서 일단은 구현만 하려고 했던 것 같은데, 이렇게 구조를 새로 잡아두면 어디에 어떤 코드를 넣을지가 더 확실하게 나와서, 요런 스파게티가 되는 부분들이 좀 더 개선될 것 같다. 후후

ㅤ

이제 구조는 잡아뒀으니, 함수 구현을 진행할 차례이다. 사실 이전에 작성해둔 로직들 재사용할 수는 있는데, 좀 지저분한 코드도 많고 잘못 구현되거나 네이밍 컨벤션이 스네이크, 파스칼, 카멜 케이스 등 다양하게 사용된 경우가 많아서 기존 로직 참고하여 로직을 새로 작성하면서 전체적으로 개선을 하려고 한다. 화이팅!

ㅤ

ㅤ

[ 변경 전 ]

ㅤ

[ 변경 후 ]