Home

Zipbab

김태영	이종성	박준식	최윤찬
@rlaxodud214	@DoTheBestMayB	@kory0115	@yoonchanchoi

App의 화면이 약 20개로 각 화면의 비즈니스 로직을 완벽하게 정의하기 어려웠기 때문에 우선 domain 레이어 없이 작성했습니다.
이후 중복되는 비즈니스 로직이 많아지면, 필요성에 따라 도입하기로 결정했습니다.
-> 기본 기능이 완료된 시점에 검토한 결과, 중복되는 비즈니스 로직이 많지 않아 도입하지 않았습니다.

The domain layer is responsible for encapsulating complex business logic, or simple business logic that is reused by multiple ViewModels.
https://developer.android.com/topic/architecture/domain-layer

BottomNavigationBar를 사용하고 있으며, Navigation Component를 통해 화면의 BackStack 관리를 원활하게 하기 위해 도입하게 되었습니다.
별도의 Task로 분리하거나 앱의 시작점이 될 수 있는 화면이 2개 이상 없었기 때문에, Multiple Activity를 선택하지 않았습니다.

Offline-First를 지원하지 않아, Local과 Remote의 DataSource가 공존할 필요가 없다고 판단했습니다.
그러나 DataSource를 사용하지 않을 경우, 결합성이 증가 하여 DataSource가 변경되면 Repository 코드도 변경해야 하는 문제점이 있습니다.
그래서 개발 기간 내에 변경 가능성이 있는지 추가로 검토했고, 없음을 확인했습니다.

계기는 최근 Android 프로젝트에서 feature 모듈을 기반으로 한 모듈화가 점점 더 많이 사용되고 있어서 직접 사용해보며 그 장점과 사용법을 이해하기 위함이였습니다.
하지만, 기획 초기 단계에서 화면에 필요한 기능과 데이터가 명확하게 정의되지 않아서, Feature 모듈을 도입하지 않았고 App(Presentation)과 Data Module만 분리해 뒀습니다.
이를 통해 추후 리팩터링에 소요되는 시간을 줄일 수 있기를 기대합니다.

과정	내용
문제	모임의 개수가 많아짐에 따라 xxx개에 달하며, 모두 표시 시 성능 문제 발생
해결책	Clustering 적용 (NaverMap - Cluster 및 Leaf Marker 적용)
결과	최적화 결과 로딩 속도 변화는 Nm/s -> Nm/s로, xx% 개선