Repository 패턴은 데이터 출처(로컬 DB인지 API응답인지 등)와 관계 없이 동일 인터페이스로 데이터에 접속할 수 있도록 만드는 것을 Repository 패턴이라고 한다.( 캡슐화 시킨것)

Repository 패턴의 궁극적인 목적은 결국 ※ 1)관심사 분리 이다. 이점은 다음과 같다.

• 하나의 도메인을 표현하는데 필요한 DataSource가 몇개 든 client쪽에서는 이를 알 필요가 없다.
• 따라서 DataSource가 새롭게 추가되는 것에 대한 부담이 없다.
• DataSource의 변경이 발생하더라도 repository 외부 layer로 전파되지 않는다.
• client는 repository 인터페이스에 의존하기 때문에 테스트하기 용이하다.
• 결국 respository는 presentation layer와 data layer 의 Coupling(결합도)를 느슨하게 만들어준다.
• 중간에 추상화된 레이어로서 Repository 클래스를 두어 모듈화가 명확해지고, 유지보수성이 향상된다.

1. 관심사의 분리가 유용한 이유는 한 영역이 다른 영역과 격리되기 때문에 다른 영역에 영향을 주지 않고도 변경할 수 있다는 것이며, 애플리케이션의 전체적인 유지보수가 용이해진다.

DataSource vs Repository

1. **DataSource**의 책임은 주로 원격 서버나 로컬 데이터베이스로부터 데이터를 가져오는 것입니다. 이 계층에서는 원시 데이터(raw data)를 그대로 반환합니다.
2. **Repository**의 책임은 데이터를 적절한 형태로 변환하여 도메인 계층에 제공하는 것입니다. 따라서 이곳에서 **DataSource**로부터 받은 원시 데이터를 도메인 객체로 변환하는 작업을 수행합니다.

이렇게 각 계층의 책임을 분리함으로써 코드의 유지보수성과 재사용성을 향상시킬 수 있습니다. **Repository**가 데이터 변환의 책임을 가지게 되면, 도메인 계층은 **Repository**로부터 도메인 객체를 받기만 하면 되므로, 데이터의 출처(원격 서버, 로컬 데이터베이스 등)나 변환 과정을 알 필요가 없습니다. 이는 단일 책임 원칙(Single Responsibility Principle)과 의존성 역전 원칙(Dependency Inversion Principle)을 따르는 것입니다.