DDD - 검색을 위해 고성능 리포지토리를 구현하는 방법

Question

DDD 및 저장소 패턴과 관련하여 질문이 있습니다.

고객 총계 루트에 대한 고객 리포지토리가 있습니다. Get & Find 메소드는 Address와 같은 객체를 포함하는 완전히 채워진 집계를 반환합니다. All good. 그러나 사용자가 UI에서 고객을 검색 할 때 요약 정보가있는 단순한 개체 인 '요약'이 필요합니다.

이 문제를 해결할 수있는 방법 중 하나는 리포지토리에서 find 메소드를 호출 한 다음 응용 프로그램 계층에서 각 고객 집계를 CustomerSearchResult/CustomerInfo DTO에 매핑하고 다시 클라이언트에 전송하는 것입니다.

하지만 내 문제는 성능입니다. 각 고객 집합은 모든 연관을 채우기 위해 여러 개의 쿼리가 필요할 수 있습니다. 따라서 내 검색 기준이 50 명의 고객과 일치하는 경우 DB에 잠재적으로 데이터를 가져올 필요가 없습니다.

다른 문제는 예를 들어 마지막으로 주문한 날짜와 같이 고객의 총 근원 경계를 벗어난 고객에 대한 요약 된 데이터를 포함 할 수 있다는 것입니다. Order는 자체 집계이므로 고객의 주문 정보를 얻기 위해서는 OrderRepository를 호출해야하며 성능이 저하됩니다.

그래서 지금 나는 두 가지 옵션이 남아 있다고 생각 :

1. 한 효율적인 쿼리를 수행하여이 요약 개체의 목록을 반환 CustomerRepository에 추가 Find 메서드를 추가합니다.

2. 은 찾기 방법 1.

설명하지만 DDD의 원칙에가는 것 같은이 두 느끼는 것을, 읽기 전용 CustomerInfoRepository 구축 목적을 만듭니다. 내 리포지토리는 일반적인 기반을 상속받습니다. Repository where T : IAggregateRoot. 이러한 요약 정보 객체는 집합체가 아니며 T와는 다른 유형이므로 실제 # 1은 디자인에 위배됩니다.

아마도 # 2에 대해 IAggregateRoot 제약 조건없이 추상 SearchRepository를 만들겠습니까?

내 도메인에는 여러 가지 유사한 시나리오가 있습니다.

이 시나리오를 어떻게 구현합니까?

덕분에, 데이브

테오의 답변을 읽은 후 업데이트

, 나는 내가 옵션 # 2로 가서 이러한 시나리오에 맞 내 인프라 내에서 전문 SearchRepository을 만들 것이라 생각합니다. 그런 다음 응용 프로그램 계층 (WCF 서비스)은 도메인 엔터티를 DTO에 매핑하는 대신 요약 DTO를 직접 채우는 리포지토리를 호출 할 수 있습니다.

**** 업데이트 2 ****

내가 난 그냥이 정확한 문제 해결을 목표로 발견 CQRS 이후했습니다 것을 추가 할 줄 알았는데 전에 년 이상이 물었다 있지만.Udi Dahan (http://www.udidahan.com/)과 Greg Young (http://codebetter.com/gregyoung/)이 그것에 대해 많은 것을 작성했습니다. DDD를 사용하여 분산 응용 프로그램을 만드는 경우 CQRS가 적합합니다!

Answer 1

요약 된 정보 만 표시하고 싶다고 생각합니다. 요약 된 정보의 이러한 비트는 도메인 모델의 엔티티 또는 값 객체가 아닙니다. 그들은 단지 정보 일 뿐이며

보고 정보를 보여주는 것과 비슷합니다. 그런 것들을 다루는다면 나는 순수한 DDD 접근법을 고수하지 않을 것입니다. 귀하의 제안 된 옵션은 귀하의 직업을 완성시키기 때문에 OK입니다. DDD는 교리로 취급되어서는 안됩니다. 상자 밖에서 생각해보십시오. 약간의 DDD 풀기.

그러나 목적을 표시하기 위해 모델 외부에 정보 값을 만 들고 있다는 점에 유의하십시오. 따라서 사용자가 도메인 모델에서 정의 된 일부 작업 정보를 선택하여 정보 값에서 식별자를 추출하고 저장소에서 엔티티/값 개체/집계를 가져와야합니다.

나는이 비디오를 강력하게 추천합니다 : Eric Evans: What I've learned about DDD since the book. 그의 책을 읽으면 전체 비디오를 볼 수 있습니다. 에릭 에반스 자신이 집계에 대해 말하고 현재 가지고있는 문제를 언급하는 약 30:00 경에 매우주의를 기울이십시오.

Answer 2

나는 것 :

1. 반환 표시 내 객체의 관점을 나타냅니다 다른 목적, 예를 들어, CustomerInfo.
2. DataTable을 반환하십시오. 종종 일반 컨테이너가 가장 쉽고 좋은 방법입니다. 당신의 일반적인 기본 저장소에있는 T가 고객 인 경우

후 나는 엄격한 Evansangelist을 모르겠지만 당신은 집계 뿌리의 개념을 잘못 적용하고 생각합니다. 필자는 DataTables 또는 고객 데이터의 뷰인 읽기 전용 객체를 포함하여 논리적으로 또는 편안하게 고객과 그룹화 된 모든 데이터를 반환 한 고객 저장소를 설계했습니다.