0. Define product

좋은 Pruduct란,

• 사용자에게 재미를 주는가?
• 사용자의 시간을 절약 해주는가?.
• 사용자의 비용을 절약 해주는가?

위의 세 가지 중 하나를 만족할 때 그 제품은 좋은 Pruduct라고 할 수 있습니다.

세가지 value를 보면 알 수 있듯이 사용자 가 중요하고 누가 사용할 것인지를 가장 먼저 생각해야 합니다.
저희 팀은 기획단계에서 부동산의 허위 매물 문제를 해결하는 제품을 개발하고자 했고, 아파트나 오피스텔을 임대차 거래하는 사람들이 매물의 빌트인이나 옵션들을 3D와 AR을 통해 자세히 보며 수리 이력도 볼 수 있는 신뢰성 있는 부동산 플랫폼에 value가 있다고 생각했습니다.

그래서, 저희 프로젝트를 다시 정리하자면,

• 어떤 제품인가? : 3D와 AR을 이용하여 에셋을 관리하는 부동산 플랫폼
• 유저가 누구인가? : 아파트와 오피스텔을 거래에 참여하는 중개소, 임대인, 임차인
• 어떤 value를 가져오는가? : 허위 매물 감소, 신뢰성 증가, 빌트인 및 옵션 관리 자동화

1. usecase

android clean architecture에서 Usecase를 정의하는 작업은 매우 중요합니다. 게다가 MVVM 패턴을 사용하여 개발하기 위해서 domain , data , presenter layer들의 역할과 구성요소를 알아야 했고, 각각의 의존성 또한 이해해야 했습니다.

참고자료 : https://soeun-87.tistory.com/25

그림의 화살표가 의존성 방향이고,
데이터흐름은 UI → Presenter→ UseCase → Entity → Repository → Data Source 순 혹은 이 역순으로 진행됩니다.

자세한 이야기는 차후 개발을 진행하면서 관련 개념이 등장할 때 다시 한번 언급하겠습니다.

일단, Usecase는 왜 사용하고 중요할까요?
간단히 말하자면 viewModel의 무게를 가볍게 하고 의존성을 줄이기 위해서 입니다. Usecase는 1개 이상의 Repository를 받아서 비즈니스 로직을 처리하는 부분입니다. (Repository는 Data Source로의 포트 역할을 한다고 생각하면 됩니다.)
따라서 Usecase가 없이 viewModel만 존재한다면, view가 필요로 하는 Data만 가지고 있으면 되는 viewModel이 Repository도 알고 있어야 하므로 의존성이 커지게 됩니다.
반대로 Usecase가 있다면, viewModel은 Repository는 몰라도 되고(의존성이 낮아진다) 어떤 데이터를 가져오거나 보여주는 행위 하나를 Usecase에서 정의해서 코드를 더욱 세분화하여 작성할 수 있습니다.

프로젝트에서 정의한 Usecase

앞으로 개발을 하고 멘토님의 피드백을 받으며 계속 추가할 것이지만, 일단 부동산 플랫폼으로서의 Usecase를 분류해보았습니다.

• 집을 구하기 위해 검색하는 케이스
• 집의 에셋을 관리하는 케이스
• 매물을 등록하는 케이스

이렇게 Usecase를 분류하고 난 뒤, 프로젝트의 hierarchy를 설계하려고 했는데 기능별로 Directory를 분류해야할지 아니면 분리된 Usecase별로 의존성을 확인한 뒤 모듈화를 해야할지 고민이 되었습니다. 그래서 다른 clean architecture 코드들을 찾아보았고,

https://github.com/android10/Android-CleanArchitecture-Kotlin

위의 레포를 참고하여 플랫폼의 코어와 기능을 분리하였습니다. 코어에는 adapter, data, ui, viewmodel 과 같은 것들이 존재하고 기능 폴더에는 저희가 사용할 3D Viewer, ARCore의 코드가 존재할 것입니다.

아직 clean architecture에 관한 공부가 부족하므로 프로젝트를 진행하며 하나하나 리팩토링하며 좋은 코드를 만들어 나갈 것입니다.

앱 아키텍처에 설계에 대한 내용은 여기까지이며, 다음으로는 Activity 및 Fragment 생성과 Bottom Navigation 구현한 내용에 대해서 포스팅 하겠습니다.