유지보수와 확장에 용이한 구조 설계

구조 도식화

이 프로젝트의 설계는 기본적으로 클린 아키텍처에 근거하여 설계 및 개발되었습니다. 이는 유지보수와 확장성을 고려한 결정이었습니다. 혼자 진행한 프로젝트이기 때문에 언제든지 기획이 변경될 수 있다고 생각했기 때문입니다.

서비스는 크게 Presentation, Domain, Data 레이어로 나누어 설계했습니다. 이러한 분리는 각 레이어의 독립성을 보장하고, 기능 추가나 수정 시 해당 레이어만을 집중적으로 업데이트할 수 있게 해줄 수 있기 때문에 프로젝트의 복잡성을 감소시킬 수 있었습니다.

예를 들어, 현재 프로젝트는 Firebase를 활용하여 데이터를 관리하고 있지만, MySQL 등 다른 데이터베이스 시스템으로 전환해야 한다면, Data 레이어의 코드만 수정하면 됩니다. 이는 다른 레이어의 코드에 영향을 주지 않으면서도, 필요한 변경을 신속하게 적용할 수 있다는 것을 의미합니다. 또한, 특정 화면의 전면적인 수정이 필요한 경우에도 Presentation 레이어만을 수정하면 됩니다.

실제로 게시물의 댓글 기능은 프로젝트 후반에 추가 되었는데, 레이어를 적절히 분리한 덕분에 기존에 사용하고 있던 이미지를 다운로드 하는 함수나 유저 정보를 가져오는 코드를 쉽게 재사용할 수 있었습니다. 결과적으로 클린 아키텍처를 도입함으로써 특정 부분의 변경이 전체 시스템에 미치는 영향을 줄이는 동시에 효율적인 개발과 유지보수할 수 있게 되었습니다.

역할 분리 기준

Presentation 레이어

• View: 사용자 인터페이스와 관련된 로직만을 포함하며, 구성 요소의 정의와 상호작용을 담당합니다. View는 UI와 직접적인 상호작용을 하는 역할만을 수행해야 합니다.
• ViewController: View와 ViewModel 사이의 중개자 역할을 합니다. 사용자의 입력을 처리하고 ViewModel의 상태 변화를 감지하여 View를 업데이트합니다.
• ViewModel: ViewController의 상태값을 보유하고, UseCase에 요청을 전달하여 상태값을 활용합니다. ViewModel은 UI 로직과 비즈니스 로직의 분리를 돕습니다.

Domain 레이어

• Entity: 비즈니스 로직의 핵심적인 데이터 구조를 정의합니다.
• UseCase: 비즈니스 로직을 수행합니다. ViewModel로부터 받은 요청을 처리하고, UI에 필요한 데이터 형식으로 가공합니다. 예를 들어, 서버에서 받은 데이터를 사용자 인터페이스에 표시하기 적합한 형태로 변환하는 역할을 합니다.

Data 레이어

• Service: 외부 데이터 소스(예: API)와의 통신을 담당합니다. Repository로부터 받은 데이터를 Domain 레이어가 이해할 수 있는 형태로 가공합니다.
• Repository: 데이터의 영속성 관리를 담당합니다. 데이터베이스나 웹 서비스 등으로부터 데이터를 CRUD하는 역할을 합니다.