아키텍처

서론

MVVM 패턴을 메인으로 클린아키텍처를 준수하여, 각 레이어 사이, 더 작게는 각 객체사이의 불필요한 의존성을 없애고자 노력하였다.

데이터 소스

데이터 소스는 실제 데이터 즉, 소스를 선별하고 소스가 있는 위치의 File, DB 등과 커넥션이 맺어져 요청과 응답을 담당하는 역할을 가진다.
데이터 소스를 원격 데이터 소스와 로컬 데이터 소스로 분리하였다. 원격과 로컬이 동일한 타입의 데이터를 반환하기 때문에 파일 및 클래스명으로 각각 어떤 역할을 하는지 명확히 구분하기 위함이다.
영속성 및 최신화가 유지되어야하는 데이터의 경우 데이터를 원격 데이터소스에 요청한다.
실시간으로 최신화 하지 않아도 되는 데이터(날씨예보)를 로컬에 저장하여 캐싱의 용도로 사용한다.

레포지토리

도메인 계층에서 원하는 데이터를 적절한 데이터 소스에게 요청하고, 데이터 소스를 통해 얻은 데이터를 도메인 계층에서 원하는 형태로 가공하여 전달한다.
레포지토리 추상클래스를 도메인 계층에 두고, 구현체를 데이터 계층에 둠으로써 데이터 계층에 대한 도메인 계층의 의존성을 역전시켰다.
캐싱 데이터, 원격 데이터를 가져 올 지를 판단하는 로직이 캡슐화 되어있고 특정 모델을 반환하는 저장소 역할을 한다.

Dto

다른 계층간의 데이터를 주고받을 수 있는 형태를 띈 객체로 주로 (모델 ⇒ Dto), (json ⇒ Dto)로 변환하는 로직이 캡슐화 되어있다.

GPS 요청이 데이터 계층에 위치한 이유

프레젠테이션, 데이터 계층 사이에서 고민이 많았지만, 특정한 정보를 요청하고 얻어온다는 점과 프레젠테이션과 데이터 계층이 결국 같은 수준의 계층이라는 점에서 데이터 계층에 두기로 결정하였다.

Facade 패턴 이 패턴을 적용한 이유

피드 작성 기능의 경우, 이미지 파일 업로드, 게시물 내용 업로드, 그리고 해당 유저의 프로필 정보에서 게시글 개수를 1 올려주는 3개의 동작으로 이루어져 있었다. 초기에는 피드 레포지토리에 유저프로필 레포지토리와 파일 레포지토리를 주입받아서 각 동작을 요청하도록 설계하였다. 하지만 이 경우, 피드 레포지토리의 책임이 많아지고, 다른 레포지토리를 의존해야 한다는 문제가 있었다.

고민한 결과로 도출된 패턴 → 퍼사드

상위의 OOTD 피드 레포지토리를 새로 만들고, 피드, 파일, 유저프로필 3개의 레포지토리를 주입받아, 각 동작을 요청하도록 하였다. 이러한 퍼사드 패턴으로 피드 게시물 작성이라는 기능에 대한 응집도를 높이고, 객체간 불필요한 결합을 해소할 수 있었다.

클린 아키텍처를 준수하기 위해 프레젠테이션, 도메인, 데이터, 3개의 계층으로 나누어 설계를 했고, 개발 역시 가장 고수준 계층인 도메인 계층부터 시작하였다. 하지만 유스케이스를 먼저 구현하다 보니 단순히 레포지토리에 데이터를 요청하는 로직만 가진 유스케이스들이 많아졌고 비즈니스 로직이라고 할 만 한 로직들은 거의 없게 되었다. 또한, 도메인 계층을 두었을 때 얻을 수 있는 장점인 코드 재사용 역시 거의 일어나지 않았다.
결과적으로 유스케이스, 즉 도메인 계층이 그다지 중요한 역할이나 책임을 갖고 있지 않은 상태였기에, 현재의 도메인 계층이 꼭 필요한지, 전체 아키텍처에서 가장 바뀌지 않을 고수준 계층인지에 대한 고려가 더 필요할 것 같다.
무조건적인 계층 분리가 항상 옳은 것은 아니며, 모바일 어플리케이션 아키텍처에서 도메인 계층이 왜 옵셔널한 지 알 수 있는 경험이 되었다. 다음부터는 중복되는 데이터 요청 로직이 생기거나, 뷰 모델에 과도하게 책임이 몰리는 경우에만 도메인 계층을 도입해야겠다고 생각했다.