본문 바로가기
Concepts/SW Design

DDD - Repository

by ocwokocw 2022. 9. 18.

- 출처: 도메인 주도 설계 - 에릭 에반스

- Repository

하나의 객체에서 다른 객체를 탐색하려면 연관관계(association)을 이용하면 된다. 하지만 객체의 생명주기 중간에도 Entity나 Value를 탐색할 수 있는 진입점이 필요하다.
 
어떤 객체의 참조를 얻기 위한 방법에는 아래와 같은 방법들이 있다.
 
  • 생성 연산으로 객체를 생성
  • 연관관계를 이용한 탐색
  • 영속화 계층으로 부터 검색
 
DB 검색은 어디서든 이용가능하며 곧바로 어떤 객체에도 접근 가능하게 해준다. 프로그램내에서 모든 객체가 서로 상호연결이 되어야 하는것은 아니다. 탐색 혹은 검색에 의존하느냐는 설계 결정 사항이다. Customer 객체가 모든 Order에 대한 컬렉션을 가지고 있는 방식이 될수도 있으며 Customer ID를 이용하여 DB에서 Order를 찾을 수도 있다. 보통 개발자들은 객체의 저장, 불러오기, 제거하는 매커니즘에만 관심을 두는데 이런 설계의 미묘한 사항도 고민해야 한다. 
 
기술적인 관점에서 저장된 객체를 불러오는것도 생성의 부분집합으로 볼 수 있다. 반면 개념적인 관점에서 보면 Entity 생명주기의 중간단계에 불과하다. 어떤 Customer 객체를 DB에 저장하고 검색하는것은 새로운 객체를 생성하는것은 아니다. 이는 저장된 객체를 인스턴스로 "재구성"하는 것이다.
 
Client는 이미 존재하는 도메인 객체를 획득할 실용적인 수단을 필요로 한다. 우리는 주로 인프라 계층을 이용하여 이런 수단을 구현한다. 인프라계층에서 도메인 객체의 참조를 제공할 때에는 주의를 기울여야 한다. 만약 질의를 통해 모든 객체를 내어준다면 Client는 자신이 정확히 필요한 세부 데이터만 얻고 비즈니스 로직을 Client 코드나 질의를 이용해서 작성하려고할 것이다.
 
따라서 객체 접근과 관련해서 어느 정도 제한을 해야한다. 우리는 앞에서 도메인 객체를 캡슐화할때 Aggregate를 사용한다는 것을 배웠다. 만약 Aggregate 내의 다른 객체에도 쉽게 접근할 수 있게 허용하면 캡슐화가 깨져 버릴 수 있다.

- Repository 구현

Repository가 이상적으로 구현되어있다면 데이터가 객체 DB, RDB, 메모리중 어디에 저장되더라도 Client 코드측의 변경이 없어야 한다.
 
Repository를 구현할때에는 아래 사항에 주의하도록 한다.
 
  • Type 추상화: Repository가 모든 타입의 인스턴스를 담기는 하지만 이것이 Class와 Repository가 1:1이라는것을 의미하지는 않는다.
  • Client 와의 분리를 활용한다.
  • Transaction 제어권을 Client 에 둔다: Repository가 데이터를 변경시키기는 하지만 보통의 경우 Commit 을 하지는 않는다. 데이터를 어느정도나 변경했을때를 하나의 작업으로 생각하느냐(Context)는 Client 가 제어하는게 적절하기 때문이다. Spring에서 Transaction 설정을 Repository가 아니라 Service에서 제어하는 이유와 연관지어서 생각해보면 이해가 더 수월할것이다.

- Factory 와의 관계

Factory와의 가장 큰 차이점은 Factory는 객체 생애의 초기 단계를 다루며 Repository는 중간 단계와 마지막 단계를 다룬다. 객체를 생성하는 Factory와 이미 저장된 객체를 재구성 Repository는 엄연히 다르다.
 
사실 프로그램 입장에서 기술적인 관점으로 보면 DB에서 데이터를 검색한 후 해당 객체를 메모리로 구성하나 프로그램 내에서 New 생성자로 객체를 새롭게 생성해서 메모리에 올리나 똑같은 입장이라 Repository와 Factory를 동일하게 생각할수도 있다.
 
하지만 모델기반의 개념적인 관점으로 보면 이를 다르게 생각할 수 있다. Factory는 새로운 객체를 만들어내는데 반해 Repository는 기존 객체를 찾아내는것이므로 Client 입장에서 바라보면 메모리상에 객체가 존재하고 있는것처럼 보이게 한다고 볼 수 있다. 따라서 가능하면 Factory 에서는 영속화에 대한 모든 책임을 빼내면 개념이 더 명확해진다.
 
 

'Concepts > SW Design' 카테고리의 다른 글

DDD - Specification  (0) 2022.09.25
DDD - 불명확한 개념  (0) 2022.09.19
DDD - Factory  (0) 2022.09.12
DDD - 도메인 객체의 lifecycle과 Aggregate  (0) 2022.09.10
DDD - Module (package)  (0) 2022.08.07

댓글