소개팅앱 만들기 두번째 프로젝트 아키텍쳐 패턴

프로젝트 시작 전 가장 고민을 많이 하고, 결정하는 사항 중 하나죠! 

프로젝트를 어떻게 설계 하냐에 따라서 추후 유지보수성에도 중요한 영향을 끼친다고 생각해요. 

물론 그냥 MVC로 가볍게 시작해도 되지만, 어차피 공부할 겸 만드는 프로젝트니까. 

최대한 나중에 유지보수 하기 쉬운 것으로 고려해서 결정해 보려고 해요. 

 

먼저 Server! 

Server는 사실 딘님이 만든 Base project가 헥사고날 아키텍처 패턴이에요. 

App만 개발하던 저 같은 클라이언트에게는 생소한 아키텍쳐 이지만,

전 CTO님의 헥사고날 아케텍쳐에 대한 생생 강의를 듣고 나니 아주 훌륭한 아키텍처라는 걸 알 수 있었어요!!

헥사고날 아키텍처의 구조는 아래 그림과 같아요.  

그림을 보면 어려워 보이지만 그냥 쉽게  비즈니스 로직과 외부 애플리케이션을 느슨하게 결합할 수 있도록 하는 게 목표인  아키텍처 에요.

단점이라고 한다면, 기능을 만들 때 생성되는 파일들이 엄청나게 많아요. 정석대로 헥사고날 아키텍처에 따라서 만들면 

로직을 구현하는 것보다 파일을 만드는데 시간이 더 소모되는 상당히 곤란해질 수 있는 상황이 연출되기 때문에, 

굳이 생략해도 되는 파일들은 가볍게 무시하고 진행하기로 해요. 

가장 중요한 건 헥사고날의 핵심인 외부 애플리케이션

즉 jpa 를 사용하던 r2dbc를 사용하던 무엇을 사용하든 쉽게 갈아 끼워서 사용할 수 있도록 만드는 거예요! 

프레임 워크에 종속적이지 않게 설계되어 있기 때문에 나중에 필요에 의해서 

Spring을 버리고 다른 걸 사용해도 돼요. 아주 좋죠?!

구조는 아래처럼 만들었어요. 

 

 

Socket 서버는 사실... 프로젝트 자체에 필요한 코드가 얼마 없어서 아키텍처를 적용할 그런 게 없어요....

이 친구는 그냥 작고 소즁하게 만들어 줍시다! 

Socket 서버야 그래도 네가 싫은 게 아니야 다만 다른 게 너무 신경 쓸게 많단다....

 

이제 제 친구 Client 를 설계해 볼까요? 

원래 Android만 놀았는데 이제 오랜 친구는 떠나보내고 

새로운 친구 Flutter랑 놀고 있어요. 

이 녀석은 혼자서 Android, iOS, web, mac, window까지 다 커버를 쳐줘요. 

저는 이 녀석으로 Android, iOS, web 까지만 개발을 해봤는데 

굉장히 만족하고 있어요. 너무 좋은 친구예요. 

 

이제 각설하고, 

Flutter는 상태 관리라는 개념이 있어요! 그냥 쉽게 설명하면 

UI와 상호 작용하는 데이터를 관리해준다라고 표현이 가능할 것 같네요. 

 

기존에 bloc을 써봤는데 이 녀석도 훌륭하지만 사실 귀찮은 게

bloc은 자식은 부모의 상태를 참조 가능하지만 역으로 참조하려면 조금 까다롭다고 해야 하나 

여하튼 너무 정석적이라. 

이번에는 provider를 좀 더 보완한 riverpod을 사용해 보려고 해요. 

 

마침 찾아보니까 훌륭한  clean architecture sample 프로젝트가 있네요. 

https://github.com/Uuttssaavv/flutter-clean-architecture-riverpod#project-description

GitHub - Uuttssaavv/flutter-clean-architecture-riverpod: Clean architecture in Flutter using Riverpod.

 

대충 저도 아래처럼 디렉터리 구성을 했어요! 

 

정리하자면

Flutter 스펙은 아래와 같아요.

통신 : dio

상태 관리 : flutter_riverpod

Local db : hive

router: go_router 

자 이제 프로젝트 구성은 어느 정도 결정이 된 것 같으니 개발을 시작해 볼까요??