Repository Pattern은 데이터 소스(data) 레이어와 비즈니스 레이어(domain) 사이에 Repository를 두어 두 레이어 사이를 중재해주는 디자인 패턴이다. 이 패턴을 적용하면 저장소를 추상화하여 데이터를 사용하는 domain 레이어에서는 데이터 소스(Local Data Source, Remote Data Source)에 상관없이 비즈니스 로직에만 집중할 수 있다는 장점이 있다.
내가 이 패턴을 접했을 때 드는 의문은 Repository 로직들은 data에 접근하는 로직인데 이 로직들이 왜 domain 로직에 해당하는걸까?하는 의문이었다.
이러한 의문을 바탕으로 Repository Pattern에 대해서 정리해보자!
domain 레이어가 Repository 인터페이스를 사용하도록 하는 이유?
domain 레이어와 data 레이어
일단 도메인 레이어의 역할에 대해서 면밀하게 살펴보자.
도메인 레이어의 역할
- 비즈니스 로직: 애플리케이션의 핵심 규칙과 정책을 정의한다.
- 도메인 모델: 애플리케이션의 주요 엔티티와 그 상호작용을 나타낸다.
- Use Cases/Interactors: 비즈니스 로직을 캡슐화하여 애플리케이션의 기능을 제공한다.
도메인 레이어란 비즈니스 로직과 관련된 규칙과 정책을 담당하는 레이어이다.
예를 들어 지금 개발하고 있는 FamilyMoments 앱의 비즈니스 로직은 다음과 같을 것이다.
- 회원 정보 가져오기
- 게시글 저장하기
- 월 별 게시글 불러오기
- 게시글의 댓글 불러오기
등등
다음으로 데이터 레이어에 대해서 살펴보자.
데이터 레이어의 역할
- 레포지토리 구현: 실제 데이터 접근 로직을 포함한다. 데이터베이스나 네트워크 API와 상호작용하여 데이터를 저장하고 조회한다.
예시로 든 FamilyMoments의 비즈니스 로직을 수행하려면 게시글, 댓글 등의 데이터를 저장하고 불러오는 로직이 필요하다. 해당 비즈니스 로직을 수행하려면 데이터 소스에 접근을 해야한다. 그러나 도메인 로직이 구체적인 데이터 소스를 알게 된다면 data source가 변경되면 많은 변경점이 생길 것이다. 따라서 추상화된 Repository를 중간에 두어 도메인 로직이 데이터 소스에 상관없이 일관적인 로직에 접근할 수 있도록 하는 것이다.
추가적으로 정리하면 다음과 같은 이유가 있다.
-
의존성 역전 원칙 (DIP): 상위 레이어(도메인 레이어)가 하위 레이어(데이터 레이어)에 의존하지 않도록 하기 위해, 도메인 레이어가 데이터 접근을 정의하고 데이터 레이어는 이를 구현한다. 이렇게 하면 도메인 레이어는 특정 데이터 저장소 구현에 의존하지 않게 된다.
-
유연성: 도메인 레이어의 코드는 특정 데이터 저장소와 독립적이므로, 데이터 저장소가 변경되더라도 도메인 로직에는 영향을 미치지 않는다. 이는 레포지토리 구현체를 쉽게 교체하거나 모킹(Mock)할 수 있게 한다.
-
테스트 용이성: 도메인 레이어의 테스트에서는 실제 데이터 저장소에 접근할 필요 없이, 레포지토리 인터페이스를 모킹하여 비즈니스 로직을 테스트할 수 있다.
안드로이드에서의 Repository와 도메인 로직 관계
안드로이드 애플리케이션에서 Repository는 데이터를 가져오고 저장하는 역할을 한다. Repository 자체가 비즈니스 로직을 포함하지 않는다. 대신, 비즈니스 로직은 Use Case 라는 별도의 컴포넌트에 포함된다. Use Case는 Repository를 호출하여 필요한 데이터를 가져오고, 이를 통해 비즈니스 로직을 수행한다.
따라서, Repository 로직이 곧 도메인 로직인 것으로 이해하기보다는, Repository는 데이터를 관리하는 역할을 하고, 도메인 로직은 Use Case에서 처리되는 것으로 이해하는 것이 정확하다. 이렇게 하면 애플리케이션의 각 레이어가 명확한 책임을 가지게 되어 유지보수성과 확장성이 높아진다.
