domain-driven-design

06장. 도메인 객체의 생명주기

Introduction

모든 객체에는 생명주기가 있다.
한 객체는 생성되어 다양한 상태를 거친 후 결국 저장되거나 삭제되면서 소멸함
도메인 객체의 관리와 관련된 문제는 아래의 두 가지 범주
- 생명주기 동안의 무결성 유지하기
- 생명주기 관리의 복잡성으로 모델이 난해해지는 것을 방지하기
본 장에서는 이러한 문제를 세 가지 패턴을 이용해 해결
- AGGREGATE (집합체)
  - 소유권과 경계를 명확히 정의함으로써 모델을 엄격하게 만들어 객체 간의 연관관계가 혼란스럽게 얽히지 않게 한다.
  - 이 패턴은 생명주기상의 전 단계에 걸쳐 도메인 객체의 무결성을 유지하는데 매우 중요
- FACTORY (팩터리)
  - 복잡한 객체와 AGGREGATE를 생성하고 재구성함으로써 그것들의 내부 구조를 캡슐화하는 것에 관해 살펴봄
- REPOSITORY (리파지터리)
  - 생명주기의 중간과 마지막을 다루며, 거대한 관련 인프라스트럭처를 캡슐화하면서 영속 객체를 찾아 조회하는 수단을 제공함
REPOSITORY 와 FACTORY 가 도메인에서 나오는 것은 아니지만, 그것들은 도메인 설계에서 중요한 역할을 담당함
이러한 구성물은 모델 객체에 쉽게 접근하는 수단을 제공해 MODEL-DRIVEN DESIGN을 완성함

AGGREGATE (집합체)

모델 내에서 복잡한 연관관계를 맺는 객체를 대상으로 변경의 일관성을 보장하기란 쉽지 않다.
그 까닭은 단지 개별 객체만이 아닌 서로 밀접한 관계에 있는 객체 집합에도 불변식이 적용돼야 하기 때문
이러한 문제가 데이터베이스 트랜잭션과 관련된 기술적 문제로 나타나더라도 문제의 근원은 모델에 경계가 정의돼 있지 않다는 데 있다.
모델을 근간으로 하는 해법을 이용하면 모델을 좀 더 이해하기 쉬워지고 설계한 바가 더 쉽게 전달될 것
먼저 우리는 모델 내의 참조에 대한 캡슐화를 추상화할 필요가 있다.
AGGREGATE 는 우리가 데이터 변경의 단위로 다루는 연관 객체의 묶음
각 AGGREGATE 에는 루트(root)와 경계(boundary)가 있다.
경계
- AGGREGATE에 무엇이 포함되고 포함되지 않는지를 정의
루트
- 단 하나만 존재
- AGGREGATE에 포함된 특정 ENTITY를 가리킴
경계 안의 객체는 서로 참조할 수 있음
경계 바깥의 객체는 해당 AGGREGATE의 구성요소 가운데 루트만 참조할 수 있음
루트 이외의 ENTITY는 지역 식별성(local identity)을 지니며, 지역 식별성은 AGGREGATE 내에서만 구분되면 됨
해당 AGGREGATE 의 경계 밖에 위치한 객체는 루트 ENTITY 의 컨텍스트 말고는 AGGREGATE 의 내부를 볼 수 없기 때문
불변식은 데이터가 변경될 때마다 유지돼야 하는 일관성 규칙을 뜻하며, 여기엔 AGGREGATE를 구성하는 각 구성요소 간의 관계도 포함될 것
한 AGGREGATE에 적용된 불변식은 각 트랜잭션이 완료될 때 이행될 것
개념적 AGGREGATE를 구현하려면 모든 트랜잭션에 적용되는 다음과 같은 규칙이 필요
- 루트 ENTITY는 전역 식별성을 지니며 궁극적으로 불변식을 검사할 책임이 있다.
- 각 루트 ENTITY는 전역 식별성을 지니고, 경계 안의 ENTITY는 지역 식별성을 지니며, 지역 식별성은 해당 AGGREGATE 안에서만 유일
- AGGREGATE의 경계 밖에서는 루트 ENTITY를 제외한 AGGREGATE 내부의 구성요소를 참조할 수 없다.
  - 루트는 VALUE OBJECT의 복사본을 다른 객체에 전달해 줄 수 있으며, 복사본에서는 어떤 일이 일어나든 문제되지 않는다.
- 데이터베이스 질의를 이용하면 AGGREGATE의 루트만 직접적으로 획득할 수 있다.
  - 다른 객체는 모두 AGGREGATE 를 탐색해서 발견해야 한다.
- AGGREGATE 안의 객체는 다른 AGGREGATE의 루트만 참조할 수 있다.
- 삭제 연산은 AGGREGATE 경계 안의 모든 요소를 한 번에 제거해야 한다.
- AGGREGATE 경계 안의 어떤 객체를 변경하더라도 전체 AGGREGATE의 불변식은 모두 지켜져야 한다.
ENTITY와 VALUE OBJECT를 AGGREGATE로 모으고 각각에 대해 경계를 정의하라.
한 ENTITY를 골라 AGGREGATE의 루트로 만들고, AGGREGATE 경계 내부의 객체에 대해서는 루트를 거쳐 접근할 수 있게 하라.
AGGREGATE 밖의 객체는 루트만 참조할 수 있게 하라.
루트를 경유하지 않고는 AGGREGATE의 내부를 변경할 수 없다.
이런 식으로 AGGREGATE의 각 요소를 배치하면 AGGREGATE 안의 객체와 전체로서의 AGGREGATE의 상태를 변경할 때 모든 불변식을 효과적으로 이행할 수 있다.
AGGREGATE를 선언하고 잠금 기법 등을 자동으로 수행하게 하는 데 기술 관련 프레임워크가 매우 유용할 수 있다.
AGGREGATE는 생명주기의 전 단계에서 불변식이 유지돼야 할 범위를 표시해준다.
FACTORY와 REPOSITORY는 AGGREGATE를 대상으로 연산을 수행하며, 특정 생명 주기 전이에 따르는 복잡성을 캡슐화함

FACTORY (팩터리)

어떤 객체나 전체 AGGREGATE를 생성하는 일이 복잡해지거나 내부 구조를 너무 많이 드러내는 경우 FACTORY가 캡슐화를 제공
객체는 그것의 존재 이유와 관련이 없거나 다른 객체와 상호작용할 때 해당 객체의 역할을 보조하지 않는 것이 아무것도 남지 않을 때까지 정제해야 하낟.
이러한 객체의 책임 중에는 전체 생명 주기의 중간 단계에서 수행해야 하는 것들이 많다.
문제는 이러한 책임만으로도 복잡한 객체에 객체 자체를 생성하는 책임까지 맡기는 데 있다.
그러나 애플리케이션에서 그와 같은 책임을 클라이언트 객체로 옮긴다면 문제가 훨씬 더 나빠진다.
객체 생성을 맡은 클라이언트는 불필요하게 복잡해지고 클라이언트가 맡고 있는 책임은 불분명해진다.
그 클라이언트는 도메인 객체와 생성된 AGGREGATE의 캡슐화를 위반한다.
더욱 안 좋은 점은 그 클라이언트가 응용 계층의 일부를 구성하고 있다면 도메인 계층에서 책임이 새어 나온다는 것이다.
어떤 객체를 생성한다는 것이 그 자체로도 주요한 연산이 될 수 있지만, 복잡한 조립 연산은 생성된 객체의 책임으로 어울리지 않는다.
클라이언트에서 직접 필요로 하는 객체를 생성하면 클라이언트 설계가 지저분해지고 조립되는 객체나 AGGREGATE의 캡슐화를 위반하며, 클라이언트와 생성된 객체의 구현이 지나치게 결합된다.
복잡한 객체를 생성하는 일은 도메인 계층의 책임이지만, 그것이 모델을 표현하는 객체에 속하는 것은 아니다.
일반적으로 객체의 생성과 조립은 도메인에서는 아무런 의미가 없지만 구현 측면에서는 반드시 필요하다.
즉, 우리가 모델 내의 어떤 것에도 해당하지 않는 요소를 설계에 추가하는 것이긴 하지만, 그럼에도 그러한 요소는 도메인 계층에서 맡고 있는 책임의 일부를 구성한다는 것이다.
자신의 책임이 다른 객체를 생성하는 것인 프로그램 요소를 FACTORY라 한다.
FACTORY는 복잡한 객체나 AGGREGATE를 생성하는 데 필요한 지식을 캡슐화한다.
FACTORY는 클라이언트의 목적과 생성된 객체의 추상적인 관점을 반영하는 인터페이스를 제공한다.
복잡한 객체와 AGGREGATE의 인스턴스를 생성하는 책임을 별도의 객체로 옮겨라.
모든 복잡한 객체 조립 과정을 캡슐화하는 동시에 클라이언트가 인스턴스화되는 객체의 구상 클래스를 참조할 필요가 없는 인터페이스를 제공하라.
전체 AGGREGATE를 하나의 단위로 생성해서 그것의 불변식이 이행되게 하라.
FACTORY를 잘 설계하기 위한 두 가지 기본 요건
- 각 생성 방법은 원자적(atomic)이어야 하며, 생성된 객체나 AGGREGATE의 불변식을 모두 지켜야 한다.
  - AGGREGATE의 불변식을 모두 지켜야 한다.
  - FACTORY는 일관성 있는 상태에서만 객체를 만들어 낼 수 있어야 한다.
  - ENTITY의 경우 이것은 전체 AGGREGATE를 생성하는 것을 의미
    - 이때 모든 불변식을 충족하고 선택적인 요소도 추가될 것
  - 불변적인 VALUE OBJECT의 경우에는 모든 속성이 올바른 최종 상태로 초기화된다는 것을 의미
- FACTORY는 생성된 클래스보다는 생성하고자 하는 타입으로 추상화돼야 한다.

FACTORY와 FACTORY의 위치 선정

일반적으로 여러분은 뭔가 감추고 싶은 세부사항이 포함된 것을 생성하고자 FACTORY를 만든 다음 그것을 여러분이 제어할 수 있는 곳에 둔다.
보통 이러한 결정은 AGGREGATE를 중심으로 이뤄진다.
예를 들어, 이미 존재하는 AGGREGATE에 요소를 추가해야 한다면 해당 AGGREGATE의 루트에 FACTORY METHOD를 만들 수도 있다.
이렇게 하면 한 요소가 추가될 때 AGGREGATE의 무결성을 보장하는 책임을 루트가 담당하고, 동시에 모든 외부 클라이언트에게서 AGGREGATE의 내부 구현을 감출 수 있다.
또 다른 예로는 생성된 객체를 소유하지는 않지만 다른 객체를 만들어내는 것과 밀접한 관련이 있는 특정 객체에 FACTORY METHOD를 두는 것
이렇게 하면 한 객체의 데이터나 규칙이 객체를 생성하는 데 매우 크게 영향을 주는 경우 어떤 다른 곳에서 해당 객체를 생성할 때 생산자의 정보를 필요로 하는 것을 줄일 수 있다.
아울러 생산자와 생성된 객체 사이의 특별한 관계를 전해주기도 한다.
FACTORY는 해당 FACTORY에서 만들어내는 객체와 매우 강하게 결합돼 있으므로 FACTORY는 자신의 생성물과 가장 밀접한 관계에 있는 객체에 있어야 한다.
대개 독립형(standalone) FACTORY는 전체 AGGREGATE를 생성해서 루트에 대한 참조를 건네주며, 생성된 AGGREGATE의 불변식이 지켜지도록 보장해준다.
특정 AGGREGATE 안의 어떤 객체가 FACTORY를 필요로 하는 데 AGGREGATE 루트가 해당 FACTORY가 있기에 적절한 곳이 아니라면 독립형 FACTORY를 만들면 된다.
하지만 AGGREGATE 내부에 접근하는 것을 제한하는 규칙을 지켜지게 하고 AGGREGATE 외부에서는 FACTORY의 생성물을 일시적으로만 참조하게 해야 한다.

생성자만으로 충분한 경우

직접적으로 생성자를 사용하는 것이 최선의 선택일 때가 있다.
FACTORY는 실제로 다형성을 활용하지 않는 간단한 객체를 이해하기 어렵게 만들 수 있다.
타협점을 고려해봤을 때 다음과 같은 상황에서는 공개 생성자 (public constructor) 를 사용하는 편이 좋다.
- 클래스가 타입인 경우
  - 클래스가 어떤 계층구조의 일부를 구성하지 않으며, 인터페이스를 구현하는 식으로 다형적으로 사용되지 않는 경우
- 클라이언트가 STRATEGY를 선택하는 한 방법으로서 구현체에 관심이 있는 경우
- 클라이언트가 객체의 속성을 모두 이용할 수 있어서 클라이언트에게 노출된 생성자 내에서 객체 생성이 중첩되지 않는 경우
- 생성자가 복잡하지 않은 경우
- 공개 생성자가 FACTORY와 동일한 규칙을 반드시 준수해야 하는 경우
  - 이때 해당 규칙은 생성된 객체의 모든 불변식을 충족하는 원자적인 연산이어야 한다.
생성자는 극도로 단순해야 한다.
AGGREGATE와 같이 복잡한 조립과정을 거쳐 만들어지는 것을 생성하려면 FACTORY가 필요하다.
또한 규모가 작은 FACTORY METHOD를 사용하는 데 드는 비용은 그리 크지 않다.

인터페이스 설계

FACTORY의 메서드 서명을 설계할 때는 해당 FACTORY가 독립형이냐 FACTORY METHOD냐에 관계없이 다음의 두 가지 사항을 명심해야 한다.
- 각 연산은 원자적이어야 한다.
  - 일관성을 지키고자 FACTORY에서 발생하는 실패에 대해 코딩 표준을 도입할 것을 고려해본다.
- FACTORY는 자신에게 전달된 인자와 결합될 것이다.
  - 입력 매개변수를 선택하는 데 신경 쓰지 않는다면 의존성의 덫이 만들어질 수 있다.
가장 안전한 매개변수는 하위 설계 계층에서 나오는 매개변수
또 다른 매개변수로 적절한 것은 모델 내의 생성물에 밀접하게 관련된 객체
구상 클래스가 아닌 추상적인 타입의 인자를 사용하라.

불변식 로직의 위치

FACTORY의 책임은 그것이 만들어내는 객체나 AGGREGATE의 불변식이 충족되도록 보장하는 것
FACTORY는 불변식 검사를 생성물에 위임할 수 있으며, 간혹 이렇게 하는 것이 최선일 때도 있다.
FACTORY의 존재 이유는 FACTORY의 생성물에 대한 구현과 밀접하게 관련돼 있다.
특정 상황에서는 불변식 로직을 FACTORY에 둬서 생성물에 들어 있는 복잡한 요소를 줄이는 것도 이점이 있다.
대체로 불변식은 모든 연산의 마지막에 적용되지만 이따금 객체에 변형하는 탓에 불변식이 결코 제 역할을 다하지 못할 때도 있다.
ENTITY가 생성되고 나면 해당 식별성은 불변성을 띠게 된다.
VALUE OBJECT는 완전히 불변적
객체는 해당 객체가 활동하는 생애 동안 결코 적용되지 않을 로직을 수행할 필요는 없다.
그런 경우에는 FACTORY가 불변식을 둘 논리적인 위치가 되며, 생성물은 더욱 단순하게 유지된다.

ENTITY FACTORY와 VALUE OBJECT FACTORY

ENTITY FACTORY는 VALUE OBJECT FACTORY 와 두 가지 점에서 다르다.
VALUE OBJECT 는 불변적
FACTORY의 연산은 생성물에 대해 풍부한 설명을 곁들여야 한다.
ENTITY FACTORY는 유효한 AGGREGATE를 만들어 내는 데 필요한 필수 속성만 받아들이는 경향이 있다.
불변식에서 세부사항을 필요로 하지 않는다면 그와 같은 세부사항은 나중에 추가해도 된다.
또 다른 차이점은 ENTITY에는 식별성 할당과 관련된 쟁점이 있다는 것
- VALUE OBJECT에는 해당하지 않음
프로그램에서 식별자를 할당하는 경우라면 FACTORY는 그와 같은 식별자를 관리하기에 적절한 곳
실질적인 고유 ID는 대개 데이터베이스의 “시퀀스(sequence)”나 기타 인프라스트럭처의 메커니즘으로 생성되지만, FACTORY에서는 무엇을 요청해야 하고 그것을 어디에 둬야 할지 알고 있을 것

저장된 객체의 재구성

재구성에 사용되는 FACTORY는 생성에 사용된 것과 매우 유사하며 주된 차이점으로는 아래의 두 가지가 있다.
- 재구성에 사용된 ENTITY FACTORY는 새로운 ID를 할당하지 않는다.
  - 저장된 객체를 재구성하는 FACTORY의 입력 매개변수에는 반드시 식별 속성을 포함해야 한다.
- 객체를 재구성하는 FACTORY는 불변식 위반을 다른 방식으로 처리할 것이다.
  - 새로운 객체를 생성하는 것보다 훨씬 더 재구성을 어렵게 만들 수 잇는 그와 같은 불일치 문제를 해결하기 위한 전략이 어느 정도 마련돼 있어야 한다.
객체 매핑 (object-mapping) 기술은 데이터베이스 재구성을 할 때 이처럼 편리한 서비스의 일부 또는 전부를 제공해줄 수 있다.
요약하면, 인스턴스 생성을 위한 접근 지점을 식별해야 하며, 그러한 접근 지점의 범위는 명시적으로 정의해야 한다.
일반적으로 FACTORY는 모델의 어떤 부분도 표현하지 않지만 해당 모델을 나타내는 객체를 뚜렷하게 드러내는 데 일조하는 도메인 설계의 일부로 볼 수 있다.
FACTORY는 객체의 생성과 재구성이라는 생명주기 전이 (transition)를 캡슐화한다.
도메인 설계를 난해하게 할 수 있는 기술적 복잡성을 노출하는 또 하나의 생명주기 전이로는 저장소에 들어갈 때와 저장소에서 나올 때 거치는 전이가 있다.
이러한 전이는 또 다른 도메인 설계 구조물인 REPOSITORY의 책임이다.

REPOSITORY (리파지터리)

객체를 이용해 뭔가를 하려면 해당 객체에 대한 참조를 가지고 있어야 한다.
- 한 가지 방법은 객체를 생성하는 것
- 두 번째 방법은 연관관계를 탐색하는 것
데이터베이스 검색은 어디서든 이용할 수 있으며, 곧바로 어떠한 객체에도 접근하게 해준다.
유감스럽게도 개발자들은 보통 그와 같은 설계의 미묘한 사항에 관해 충분히 고민하지 않곤 하는데, 이것은 개발자들이 객체를 저장하고 그것을 다시 가져오고, 결국 객체를 저장소에서 제거하는 요령을 알아내는 메커니즘에만 관심을 두기 때문
이제 기술적 관점에서 보면 저장된 객체를 가져오는 것은 실제로는 생성의 한 부분집합으로 볼 수 있다.
- 이는 데이터베이스에서 가져온 데이터를 토대로 새로운 객체를 만들어내기 때문
하지만 개념상 이것은 특정 ENTITY의 생명주기 가운데 중간 단계에 불과하다.
이러한 구분을 염두에 두고자 저자는 저장돼 있는 객체로부터 인스턴스를 만들어 내는 것을 재구성(reconstitution)이라고 한다.
도메인 주도 설계의 목표는 기술보다는 도메인에 대한 모델에 집중해 더 나은 소프트웨어를 만들어내는 것
메타데이터 매핑 계층과 같은 인프라스트럭처는 질의 결과를 손쉽게 객체로 변환할 수 있어 굉장히 도움되지만 개발자들은 여전히 도메인이 아닌 기술적 메커니즘에 관해 생각하게 된다.
더 안 좋은 점은 클라이언트 코드에서 직접적으로 데이터베이스를 사용할수록 개발자들은 AGGREGATE 나 캡슐화와 같은 특징을 활용하는 것을 우회하려 하고, 그 대신 필요한 데이터를 직접 획득해서 조작하게 된다는 것
클라이언트는 이미 존재하는 도메인 객체의 참조를 획득하는 실용적인 수단을 필요로 한다.
인프라스트럭처에서 도메인 객체의 참조를 쉽게 획득할 수 있게 해준다면 클라이언트 측을 개발하는 개발자들이 좀 더 탐색 가능한 연관관계를 추가해 모델을 엉망으로 만들어 버릴지도 모른다.
더 중요한 것은 AGGREGATE 내부에 존재하는 모든 객체는 루트로부터 탐색을 토대로 접근하는 것 말고는 접근이 금지돼 있다는 점이다.
대개 영속화된 VALUE OBJECT 는 그것들을 캡슐화하고 AGGREGATE 의 루트 역할을 하는 특정 ENTITY 에서부터 탐색해서 찾을 수 있다.
대부분의 객체는 전역적인 검색으로 접근하지 말아야 한다는 점이 분명해진다.
이러한 점이 설계에 드러아면 바람직할 것
영속 객체는 해당 객체의 속성에 근거해서 검색하는 식으로 전역적으로 접근할 수 있어야 한다.
그러한 접근 방식이 필요한 곳은 탐색으로 도달하기에는 편리하지 않은 AGGREGATE 의 루트다.
일반적으로 루트는 ENTITY 이며, 간혹 복잡한 내부 구조를 지닌 VALUE OBJECT 이거나 열거형 VALUE 이기도 하다.
다른 객체에도 접근할 수 있게 한다면 중요한 구분법이 혼동될 것
REPOSITORY는 특정 타입의 모든 객체를 (대개 모방된) 하나의 개념적 집합으로 나타낸다.
더욱 정교한 질의 기능이 있다는 점을 제외하면 REPOSITORY 는 컬렉션처럼 동작한다.
이 같은 정의에는 생명주기의 초기 단계에서 마지막 단계에 이르기까지 AGGREGATE 의 루트에 대한 접근을 제공하는 각종 응집력 있는 책임이 포함된다.
REPOSITORY 는 클라이언트에서 요구하는 기준에 근거해 객체를 선택하는 다양한 질의를 구현할 수 있다.
객체를 추가하고 제거하는 메서드를 제공하고, 이 메서드가 실제로 데이터 저장소에 데이터를 삽입하고 데이터 저장소에서 제거하는 연산을 캡슐화하게 하라.
실질적으로 직접 접근해야 하는 AGGREGATE 의 루트에 대해서만 REPOSITORY 를 제공하고, 모든 객체 저장과 접근은 REPOSITORY 에 위임해서 클라이언트가 모델에 집중하게 하라.
REPOSITORY 에는 다음과 같은 이점이 있다.
- REPOSITORY는 영속화된 객체를 획득하고 해당 객체의 생명주기를 관리하기 위한 단순한 모델을 클라이언트에 제시
- REPOSITORY는 영속화 기술과 다수의 데이터베이스 전략, 또는 심지어 다수의 데이터 소스로부터 애플리케이션과 도메인 설계를 분리
- REPOSITORY는 객체 접근에 관한 설계 결정을 전해준다.
- REPOSITORY를 이용하면 테스트에서 사용할 가짜 구현을 손쉽게 대체할 수 있다.
  - 보통 메모리상의 컬렉션을 이용

REPOSITORY에 질의하기

모든 REPOSITORY는 클라이언트가 특정 기준에 부합하는 객체를 요청할 수 있는 메서드를 제공하며, 이러한 인터페이스를 설계하는 방법에는 여러 가지가 있다.
가장 만들기 쉬운 REPOSITORY는 질의에 구체적인 매개변수를 직접 입력하는 것
대부분의 질의가 한 객체나 객체의 컬렉션을 반환하기도 하지만, 질의는 특정 유형의 요약 연산을 반환한다는 개념에도 잘 맞아떨어진다.
프레임워크를 토대로 REPOSITORY 를 일반화하는 한 가지 특별히 적절한 접근법은 SPECIFICATION (명세) 에 기반을 둔 질의를 사용하는 것
SPECIFICATION을 이용하면 클라이언트가 질의의 획득 방법에 대해서는 신경 쓰지 않고도 원하는 바를 서술할 수 있다.
SPECIFICATION 기반 질의는 우아하고 유연하다.
그러나 유연한 질의를 이용하는 REPOSITORY 설계에서도 특별히 직접 입력된 질의를 추가할 수 있어야 한다.
이러한 부가적인 요소를 제공하는 것이 불가능한 프레임워크는 도메인 설계를 왜곡하거나 개발자들이 해당 프레임워크를 우회해서 뭔가를 하게 만들 것

클라이언트 코드가 REPOSITORY 구현을 무시한다 (개발자는 그렇지 않지만)

영속화 기술을 캡슐화하면 클라이언트가 매우 단순해지고 REPOSITORY 구현에서 완전히 분리된다.
그러나 캡슐화가 종종 그렇듯이 개발자들은 무슨 일이 일어나고 있는지 반드시 알고 있어야 한다.
REPOSITORY가 의도하지 않은 방식으로 사용되거나 작동한다면 REPOSITORY의 수행 성능이 극단에 치우칠 수 있다.
개발자들은 캡슐화된 행위를 활용하는 것에 내포된 의미를 알아야 한다.
그러나 그것이 구현상의 상세한 내용까지 잘 알고 있어야 한다는 의미는 아니다.
잘 설계된 컴포넌트라면 특징이 잘 드러날 수도 있다.

REPOSITORY 구현

이상적인 모습은 클라이언트에서 모든 내부 기능을 감춰서 데이터가 객체 데이터베이스나 관계형 데이터베이스에 저장되든, 아니면 단순히 메모리상에 상주하느냐에 관계없이 클라이언트 코드를 동일하게 유지하는 것
저장, 조회, 질의 메커니즘을 캡슐화하는 것은 REPOSITORY 구현의 가장 기본적인 기능
REPOSITORY 의 개념은 여러 상황에 적용할 수 있다.
명심해야 할 몇 가지 중요한 사항
- 타입을 추상화한다.
  - 명심할 점은 현재 이용 중인 데이터베이스 기술에는 그와 같은 다형성이 존재하지 않아서 발생할 수 있는 제약조건에 마주치게 될지도 모른다는 것
- 클라이언트와의 분리를 활용한다.
  - 이렇게 하면 클라이언트에서 직접 메커니즘을 호출했을 때보다 더 자유롭게 REPOSITORY의 구현을 변경할 수 있다.
  - 이로써 영속화 전략을 자유롭게 교체하면서 질의 기법을 다양하게 하거나 메모리상에 객체를 캐싱해 성능을 최적화할 수도 있다.
- 트랜잭션 제어를 클라이언트에 둔다.
  - 만약 REPOSITORY에서 간섭하지 않는다면 트랜잭션 관리가 좀 더 단순해질 것
자바와 같은 언어의 타입 체계를 이용하면 이러한 접근법에서 반환되는 객체는 “Object”로 한정되므로 클라이언트에서는 REPOSITORY에 포함된 타입으로 객체를 형변환해야 한다.
하지만 어쨌든 자바에서는 컬렉션을 반환하는 질의로 이렇게 해야 할 것

프레임워크의 활용

REPOSITORY와 같은 것을 구현하기 전에 먼저 현재 사용 중인 인프라스트럭처, 특히 모든 아키텍처 프레임워크에 관해 곰곰이 생각해봐야 한다.
일반적으로 현재 사용 중인 프레임워크를 자신의 요구에 억지로 맞추려 해서는 안된다.
도메인 주도 설계의 원칙을 유지할 수 있는 방법을 찾고 프레임워크가 자신의 요구와 맞지 않은 경우에는 명세를 준수한다.
도메인 주도 설계의 개념과 프레임워크의 개념 사이의 유사성을 찾아본다.
이는 우리들이 프레임워크를 사용할 수 밖에 없는 경우를 전제한다.

FACTORY와의 관계

FACTORY가 객체 생애의 초기 단계를 다루는 데 반해 REPOSITORY는 중간 단계와 마지막 단계를 관리하는 데 도움된다.
REPOSITORY 가 데이터를 근거로 객체를 생성하므로 많은 이들이 REPOSITORY를 FACTORY 로 생각하는데, 사실 기술적 관점에서는 그렇다고 볼 수 있다.
그러나 모델에 중심을 두는 것이 더 유용하며, 앞에서 언급한 것처럼 저장된 객체를 재구성하는 것이 새로운 개념적 객체를 생성하는 것은 아니다.
설계를 이러한 주요한 도메인 주도 관점에서 보면 FACTORY와 REPOSITORY의 책임이 뚜렷이 구분되는데, FACTORY가 새로운 객체를 만들어 내는 데 반해 REPOSITORY는 기존 객체를 찾아낸다.
이러한 두 가지 관점은 REPOSITORY가 맨 처음으로 객체를 생성하는 데도 사용할 수 있는 FACTORY로 객체 생성을 위임해서 일치시킬 수 있다.
FACTORY에서 영속화에 대한 모든 책임을 빼내는 것은 이러한 명확한 분리에도 도움된다.
사람들이 FACTORY와 REPOSITORY를 결합하게 만드는 또 한 가지 경우는 “찾아서 없으면 생성하는 (find or create)” 기능을 원할 때
- 이 기능을 사용하는 것을 자제해야 한다.
- 이 기능은 기껏해야 조금 더 편리할 뿐
- 이 기능이 유용해 보일 때는 대부분 ENTITY와 VALUE OBJECT가 확연히 구분되는 경우밖에 없다.
일반적으로 새로운 객체와 이미 존재하는 객체를 구분하는 것은 도메인에서 중요하며, 그리고 그것들을 투명하게 결합하는 프레임워크는 실제로 상황을 엉망으로 만들어버릴 것

관계형 데이터베이스를 위한 객체 설계

객체지향 소프트웨어 시스템에서의 가장 일반적인 비객체 구성요소는 주로 관계형 데이터베이스
데이터베이스는 단순히 객체와 상호작용하는 것만은 아니며, 객체 자체를 구성하는 데이터의 영속적인 형태를 저장
둘 사이의 매핑을 생성하고 관리하는 데 사용되는 상당히 세련된 도구도 있다.
기술적 관점은 별도의 문제로 하더라도 이 같은 불일치는 객체 모델에 상당한 영향을 줄 수 있다.
아래는 세 가지 공통적인 경우를 나열한 것
- 데이터베이스가 주로 객체를 저장하는 저장소인 경우
- 데이터베이스가 다른 시스템에서 사용될 용도로 설계된 경우
- 데이터베이스가 현행 시스템에서 사용될 용도로 설계됐으나 객체 저장 이외의 역할을 하는 경우
문제는 여러 겹으로 교차하는 모델이 너무 복잡하는 것
매핑 도구의 기능에 따라 일부 객체의 애그리게이션(aggregation)이나 컴포지션(composition)이 가능할 것
그러나 매핑은 투명해야 하고, 매핑 도구에 작성된 코드를 검사하거나 항목을 읽기만 해도 쉽게 이해할 수 있어야 한다는 점이 중요
데이터베이스가 하나의 객체 저장소로 보여진다면 매핑 도구의 기능과는 상관없이 데이터 모델과 객체 모델이 서로 갈라지게 해서는 안된다.
- 객체 매핑을 단순화하는 데 도움된다면 정규화와 같은 정형화된 관계 표준을 절충한다.
객체 시스템의 외부의 프로세스는 이러한 객체 저장소에 접근해서는 안된다.
- 그러한 프로세스는 객체에 적용된 불변식을 위반할 수 있기 때문
- 그뿐만 아니라 그러한 프로세스가 접근하게 되면 데이터 모델을 고착화해서 객체를 리팩터링할 때 변경하기가 힘들어진다.
객체지향 도메인은 영속적인 형태로 표현하는 관계형 데이터베이스의 경우에는 단순하게 직접적으로 표현하는 편이 가장 좋다.
UBIQUITOUS LANGUAGE 는 객체와 관계형 구성요소를 하나의 모델로 묶는 데 이바지할 수 있다.
객체 세계에서 빠르게 확립되고 있는 리팩터링은 사실 관계형 데이터베이스 설계에는 크게 영향을 주지 못했다.
게다가 중요한 데이터 마이그레이션 문제는 빈번한 변경을 단념하게 만든다.
모델과 데이터베이스 간의 관계를 끊는 것은 현혹적인 경로에 해당한다.
이것은 팀이 데이터베이스와 모델의 대응을 유지하는 데 실패할 때 부지불식간에 받아들여지곤 한다.
하지만 모델과 데이터베이스를 의식적으로 분리한 경우라면 기존의 객체 모델을 따르는 절충안으로 가득 찬 부자연스러운 데이터베이스 스키마가 아닌 깔끔한 데이터베이스 스키마가 만들어질 수 있다.