[도메인 주도 설계] 06. 도메인 객체의 생명주기 (2)

REPOSITORY (리파지터리)

• 객체를 이용하기 위해서는 객체에 대한 참조가 필요하다.
• 객체의 참조를 얻는 방법은
  1. 객체를 생성
  2. 이미 알고있는 객체로부터 연관관계를 탐색
  3. 데이터베이스에서 질의를 통해 획득
• 이 중 3번의 방식은 질의 결과를 손쉽게 객체로 변환할 수 있어 도움이 되지만 남용할 경우 문제가 있다.
  1. 도메인이 아닌 기술적 메커니즘에 관해 더 생각하게 된다.
  2. AGGREGATE나 캡슐화 같은 특징을 활용하는 것을 우회하려 하고, 데이터를 직접 획득해서 조작하게 된다.
  3. 도메인 로직이 질의와 클라이언트 코드로 들어가고, ENTITY와 VALUE OBJECT는 데이터 컨테이너로 전락한다.
  4. 도메인 계층에 대한 개발자들의 이해 수준을 낮춰 모델과 도메인 계층을 동떨어진 것으로 만든다.

• REPOSITORY를 사용하면 위의 문제를 해결할 수 있다.
  

  

• REPOSITORY의 이점
  • 영속화된 객체를 획득하고 해당 객체의 생명주기를 관리하기 위한 단순한 모델을 클라이언트에게 제공한다.
  • 영속화 기술과 다수의 데이터베이스 전략 및 다수의 데이터 소스로부터 애플리케이션과 도메인 설계를 분리해준다.
  • 객체 접근에 관한 설계 결정을 전해준다.
  • 테스트에서 사용할 가짜 구현을 손쉽게 대체할 수 있다.(메모리 상의 컬렉션을 이용)
• REPOSITORY에 질의하기
  • 구체적인 매개변수를 직접 입력하는 질의
    • 가장 만들기 쉬움
    • 특정 유형의 요약 연산을 반환한다는 개념과도 잘 맞아떨어짐
      

      

  • SECIFICATION(명세)에 기반을 둔 질의
    • 클라이언트가 질의의 획득 방법에 신경쓰지 않고 원하는 바를 획득할 수 있음
    • 사용 가능한 인프라스트럭처에 따라 적용하기 어려울 수도 있음
      

      

  • 클라이언트 코드가 REPOSITORY 구현을 무시한다 (개발자는 그렇지 않지만)
    • REPOSITORY가 의도하지 않은 방식으로 사용된다면 수행 성능이 극단에 치우칠 수 있다.
    • 상세한 구현까지는 아니더라도 캡슐화된 행위를 활용하는 것에 내포된 의미를 알아야 한다.
  • REPOSITORY 구현
    • 타입을 추상화한다.
      • 타입은 인터페이스가 될 수도 있고 구체적인 구상 클래스가 될 수도 있다.
    • 클라이언트와의 분리를 활용한다.
      • REPOSITORY의 구현을 자유롭게 변경할 수 있게 된다.
      • 영속화 전략을 자유롭게 교체할 수 있게 된다.
    • 트랜잭션 제어를 클라이언트에 둔다.
      • 트랜잭션 관리가 좀 더 단순해진다.
  • FACTORY와의 관계
    • FACTORY가 새로운 객체를 만들어 내는 데 반해 REPOSITORY는 기존 객체를 찾아낸다.
      

      

       
    • FACTORY는 객체를 인스턴스화하고, 클라이언트는 객체를 REPOSITOY에 추가한다. REPOSITORY는 데이터베이스 내의 객체 저장소를 캡슐화한다.

      

       
  • 관계형 데이터베이스를 위한 객체 설계
    • 관계형 데이터베이스는 비객체 구성요소이다. 그러나 데이터베이스는 다른 구성요소에 비해 객체 모델에 직접적으로 관련되어 있다. 이러한 불일치는 객체 모델에 영향을 줄 수 있다.
    • 매핑 도구가 충분히 정교하기 때문에 관계형 테이블 설계에서 도메인 모델을 반영할 필요는 없다.
      하지만 MODEL-DRIVEN DESIGN에 제기된 주장들(분석 모델과 설계 모들의 분리를 피하자)을 받아들이자면
      • 어느정도 객체 모델의 풍부함을 희생해야 하고
      • 데이터베이스 설계도 변경(선태적 비정규화 같은)해야 한다.
      • 그렇지 않으면 모델과 구현 간의 밀접한 결합을 잃어버릴 수 있다.
    • 매핑은 투명해야 하고, 매핑도구에 작성된 코드를 통해 쉽게 이해할 수 있어야 한다.
      • 데이터 모델과 객체 모델이 서로 갈라지게 해서는 안된다.
        • 일부 객체 관계의 풍부함을 희생해서 관계 모델에 밀접하게 한다.
        • 정규화같은 정형화된 관계 표준을 절충해서 객체 매핑을 단순하게 한다.
      • 객체 시스템 외부의 프로세스는 이러한 객체 저장소에 접근해서는 안된다.