도메인 주도 설계 구현

리파지토리(repository)

리파지토리는 보통 저장소의 위치를 말하는데 주로 그안에 저장된 항목의 안전이나 보존을 위한 장소로 여긴다.
이런 기본적인 원리들은 DDD 리파지토리에도 적용된다.

일반적으로 애그리게잇 타입과 리파지토리 사이에는 일대일의 관계가 성립한다.
정확히 말하자면 애그리게잇만이 리파지토리를 갖게 된다.

컬렉션 지향 설계는 전통적인 접근법

컬렉션 지향 리파지토리에서 기억해야 할점

리파지토리는 set 컬렉션을 흉내 내야 한다. 특정 영속성 메커니즘을 지탱하는 구현이 무엇이든 같은 객체의 인스턴스는 두번 추가되도록 허용해선 안된다.

영속성 객체에 일어난 변화를 암시적으로 추적하는 기능을 제공해야 한다.

암시적 읽기 시 복사 : 이 영속성 메커니즘은 저장소로부터 읽어와 재구성할 때 암시적으로 각 영속성 객체의 복사본을 만들고 커밋시에
클라언트의 복사본과 자신의 복사본을 비교한다. 변경이 감지된 모든 객체는 데이터 저장소의 반영한다.
암시적 쓰기 시 복사 : 영속성 메커니즘은 모든 로드된 영속성 객체를 프록시를 통해 관리한다. 프록시는 관리 되는 객체의 상태에 일어난 변화를 추적해 터티로 표시한다.
트렌젝션이 커밋되면 터티한 객체를 모두 찾아서 데이터 저장소로 반영시킨다.

모든 도구를 사용할 땐 그에 따르는 반작용을 완전히 숙지 해야된다.

하나의 트랜젝션에서 다수의 애그리게잇 인스턴스를 추가하거나 삭제하는것이 적절하지 않을수도 있다.

영속성 메커니즘이 암묵적으로나 명시적으로나 객체의 변화를 감지하고 추적하지 못할때에는 영속성 지향의 저장 기반 리파지토리를 사용해야된다.

1
2
3

영속성 지향 리파지토리에서 기억할 점

우리는 명시적으로 새롭고 변경된 객체를 저장소에 put()해야 하는데 이전에 주어진 키와 연관된 모든 값을 효과적으로 대체해야 한다.

도메인 모델과 이를 둘러싸는 도메인 계층은 트랜잭션을 관리하기에 올바른 장소가 아니다. 모델과 연관된 오퍼레이션 자체가 트랜잭션을 관리하기에는
일반적으로 그 단위가 너무 작고 그들의 수명주기에 트랜잭션이 영향을 미쳐서도 안된다.

트랜잭션을 과도 하게 사용하지 말아라 단일 트랜잭션에서 여러 애그리게잇의 수정을 커밋하는 기능을 과도하게 사용하지 않도록 주의하라

객체지향 언어를 사용해서 도메인 모델을 개발할 때 타입 계층구조를 만들기 위해 상속을 사용하려는 유혹에 빠질수 있다.

내부의 디스패치가 지저분해지면 언제든 더 작은 계층구조를 또 하나 설계해서 이를 처리학도록 하면 된다.

DAO는 데이터베이스 테이블에 따라 표현되면 CRUD 인터페이스를 제공한다.

리파지토리를 일반적 관념에서 DAO로 생각할 수도 있다. 하지만 중요한점은 가능한 데이터 엑세스 지향보다는 컬렉션 지향으로 설계하려고 노력해야 한다.

리파지토리의 테스트를 바라 보는 두가지 경향