DataSource / Repository / Implement 에 대한 차이점 정리

 

클린아키텍처로 flutter 프로젝트를 진행하고 있는데 비슷한 용어가 여기저기서 다양하게 사용되다보니

개념이 헷갈려서 아래 구성항목들에 대해서 오늘 다시한번 정리해보려고 한다.

 

1. Data Source
2. Data Source Implement
3. Repository
4. Repository Implement
   
   

---

Data Source

• 역할 : 외부로부터 데이터를 가져오거나 저장하는 방법을 정의한다.
  → 데이터의 출처(DB, API 등)에 접근하는 방법(상호작용)을 추상화 한다.
  • 여기서 추상화란 ?
    : 복잡한 시스템의 세부사항을 숨기고 핵심적인 부분만 드러내는 것
    
    
• 비유 : 요리 레시피 + 주방
  → 필요한 재료와 메서드 순서 등을 정의하지만 실제로 요리하지 않는다.
  → 어떤 데이터를 어디서 가져올것인가(레스토랑 밖이 될 수도 있음)에 대한 메서드만 정의한다.
  
  
•  

Data Source Implement

• 역할 : 데이터 소스 인터페이스 안에 정의된 데이터를 실제로 구현한다.
  즉, 실제 DB, API 등과 통신하는 로직을 담는다.
  (ex. Firebase DB에서 컬렉션 및 문서 안에서 정보를 가져오는 로직)
  
  
• 특징 :
  • 인터페이스 이름에 Impl이라는 접미사를 붙여 구현체임을 명시한다.
  • API호출(http 패키지 필요)을 수행하거나, 로컬 DB에 접근하는 등의 구체적인 구현 로직을 포함한다.
    
    
• 비유 : 요리사
  → 데이터 소스 인터페이스에 정의된 메서드를 구현한다.
  → 실제 데이터 소스 (DB, API 등) 에서 데이터를 가져온다.
  
  

---

Repository

• 역할 : 도메인 / 데이터 레이어 간의 중재자 역할을 한다.
  여러 데이터 소스를 사용하여 데이터를 가져오고, 추가적으로 데이터 변환이나 캐싱 등을 수행한다.
  
  
• 특징 :
  • 도메인 레이어에서 필요로 하는 형태로 데이터를 제공
    • getUser, updateUser, deleteUser 등의 메서드가 필요하다고만 정의해둠.
• 비유 : 레스토랑 메뉴판
  → 어떤 데이터소스로 어떤 메서드를 쓸것인지만 알수 있음.
  → 할 수 있는것은 레스토랑 내부(프로젝트 내부)에서 하는 일밖에 없음.
  
  

Repository Implement

• 역할 : 도메인 레이어의 요청을 받아 여러 데이터 소스를 조합하여 비즈니스 로직 처리
• 비유 : 레스토랑 웨이터 + 주방
  → Usecase(주문) 입력받아 Dto(주문서. 필요한 데이터만 담음.)형태로 요청하면 Entity(요리)가 생성됨.