저장소 패턴 (Repository Pattern)
영속적 저장소를 추상화한다.
Repository
전역적인 접근이 필요한 각 객체 타입에 대해 메모리상에 해당 타입의 객체로 구성된 컬렉션이 있다는 착각을 불러 일으키는 객체를 만든다. 잘 알려진 전역 인터페이스를 토대로 한 접근 방법을 마련하라. 객체를 추가하고 제거하는 메서드를 제공하고, 이 메서드가 실제로 데이터 저장소에 데이터를 삽입하고 데이터 저장소에서 제거하는 연산을 캡슐화하게 하라. 특정한 기준으로 객체를 선택하고 속성값이 특정 기준을 만족하는 완전히 인스턴스화된 객체나 객체 컬렉션을 반환하는 메서드를 제공함으로써 실제 저장소와 질의 기술을 캡슐화하라. 실질적으로 직접 접근해야 하는 AGGREGATE의 루트에 대해서만 REPOSITORY를 제공하고, 모든 객체 저장과 접근은 REPOSITORY에 위임해서 클라이언트가 모델에 집중하게 하라. 1
- 저장소는 DB 접근을 추상화한다.
- DB가 마치 인메모리에만 있는 것처럼 착각하게 하여, 개발자가 DB 입출력에 대한 고민이 아니라 모델링에 대한 고민에 몰두하게 하는 것이 중요하다.
의도
에릭 에반스는 다음과 같이 REPOSITORY의 의도에 대해 언급한다.
마음대로 데이터베이스에 질의를 수행하면 실제로 도메인 객체와 AGGREGATE의 캡슐화를 어길 수도 있다. 기술적 인프라스트럭처와 데이터베이스 접근 메커니즘을 드러내면 클라이언트가 복잡해져서 MODEL-DRIVEN DESIGN이 불분명해질 것이다.
데이터베이스 접근과 관련된 기술적 어려움을 다루는 기법은 아주 많다. 그러한 예로 SQL을 QUERY OBJECT(질의 객체)로 캡슐화하는 것과 METADATA MAPPING LAYER(Martin Fowler 2003)를 이용해 객체와 테이블 사이를 번역하는 것이 있다. FACTORY는 저장된 객체를 재구성하는 데 도움될 수 있으며(이 장의 후반부에서 논의하겠다), 이것을 비롯한 다른 여러 기법들은 복잡성을 감추는 데 이바지한다.
하지만 그렇더라도 우리가 놓친 건 없는지 주의를 기울여야 한다. 우리는 더 이상 도메인 모델에 포함된 개념에 관해서는 생각하지 않고 있다. 이렇게 되면 우리가 작성하는 코드는 업무에 관해 전해주지 않을 것이며, 코드는 데이터 조회 기술을 다루게 될 것이다. REPOSITORY 패턴은 그와 같은 해법을 캡슐화해서 우리를 다시 모델에 집중하게 해주는 단순한 개념적 틀에 해당한다. 2
- DB 접근을 추상화하는 기법은 다양하게 알려져 있다.
- SQL QUERY OBJECT, METADATA MAPPING LAYER, FACTORY 같은 기법을 사용하면 DB 접근과 관련된 복잡성을 감추는 데 도움이 된다.
- 그러나 이런 종류의 코드를 통해 "업무"가 아니라 "데이터 조회 기술"에 몰두하게 된다면 바람직하지 않을 수 있다.
- REPOSITORY 패턴은 "데이터 조회 기술"을 캡슐화하여, 우리가 모델에 집중할 수 있도록 도와주는 도구다.
From: 파이썬으로 살펴보는 아키텍처 패턴
저장소 패턴은 영속적 저장소를 추상화한 것이다. 저장소 패턴은 모든 데이터가 메모리상3에 존재하는 것처럼 가정해 데이터 접근과 관련된 지루한 세부 사항을 감춘다. 4
- 저장소 패턴은 영속적 저장소에 대한 단순한 추상화다.
저장소는 컬렉션이 메모리상에 있는 객체라는 환상을 제공한다. 저장소를 사용하면 핵심 애플리케이션에는 영향을 미치지 않으면서 인프라를 이루는 세부 구조를 변경하거나 FakeRepository를 쉽게 작성할 수 있다. 5
참고문헌
- 도메인 주도 설계 / 에릭 에반스 저 / 이대엽 역 / 위키북스 / 초판발행 2011년 07월 21일 / 원제 : Domain-Driven Design
- 파이썬으로 살펴보는 아키텍처 패턴 / 해리 퍼시벌, 밥 그레고리 저/오현석 역 / 한빛미디어 / 2021년 06월 03일 / 원서 : Architecture Patterns with Python