DDD 저장소 EF 성능

Question

DDD를 따르는 사람들이 EF 및 저장소 패턴을 사용하여 잠재적 인 성능 문제를 해결하고 아이들과 함께 루트를 반환하는 방법에 대해 궁금합니다.

부모 ----- 어린이 A

또는 예를 들어. 부모 ----- 아이 ------- 아이 A2

1. 내가 저장소에서 집계 루트의 데이터를 다시 가져올하고 있기 때문에 다음 다른 쿼리를 발생시키는 탐색 속성 EF를 사용하는 경우 게으른로드 불러 오기. 이것은 루프에있을 때 100 개 이상의 쿼리가 발생하기 때문에 문제가됩니다.
2. 'Include'문을 사용하여 하위 데이터가 포함 된 저장소의 집계 루트 데이터를 다시 가져 오는 경우 하위 데이터를 부모 저장소와 함께 가져옵니다. 그런 다음 탐색 속성을 사용할 때 해당 데이터가 이미 메모리에 있으므로 쿼리가 실행되지 않습니다.

두 번째 방법의 문제점은 하위 개체에 대한 일부 데이터가 매우 클 수 있다는 것입니다. 100,000+ 개 레코드. 분명히 나는 ​​아이를위한 메모리에 100,000 개 이상의 레코드를 저장하고 싶지 않습니다. 우리는이 문제를 해결하기 위해 한 번에 10 개씩 페이징을 선택하기로 결정했으나 또 다른 문제는 합계, 총 카운트 등과 같은 계산을 아이들이 사용하려고 할 때이지만 우리가 가지고있는 10 개의 레코드 당겨.

DDD 방식은 객체 그래프를 메모리에 모두 가져 와서 표시해야하는 데이터에 대한 객체를 통과하는 것입니다.

Google 팀에 스플릿이 있습니다. 일부는 집계 루트와 그 자식을 함께 가져와야한다고 생각하고 일부는 하위 데이터를 직접 쿼리하고 하위 개체를 가져 오는 집계 루트 저장소에서 메소드를 가져야한다고 생각합니다. .

난 부모/자식과 함께 메모리에 저장된 많은 양의 데이터로 인해 다른 사람들이 성능 문제를 어떻게 해결했는지 궁금합니다.

Answer 1

성능을 처리해야한다면 리포지토리에 노출 된 특별한 방법으로 두 번째 방법을 사용해야합니다. 즉, 그러한 방법을 제공하는 저장소 지점 인 반면에 EF 컨텍스트/직접 사용할 수 있습니다.

이론 데이터로 작업하는 경우 이론이 좋습니다. 실제 데이터가 있으면 실제 시나리오에서 작동하도록 이론을 조정해야합니다.

this article (블로그에는 다음 3 개 기사가 있음)을 확인할 수도 있습니다. 두 번째 방법이지만 첫 번째 방법 인 것처럼 가장합니다. Count에서 작동하지만 어쩌면 다른 시나리오에서도 사용할 수 있습니다.

Answer 2

DDD 방식은 항상 필요한 모든 데이터를 되돌릴 수있는 것은 아닙니다. 하나의 기술로 double dispatching이라는 패턴을 사용합니다. 여기서 필요한 모든 매개 변수를 사용하여 집계 루틴의 메소드 (또는 도메인 서비스)를 호출하지만 '쿼리 전용'저장소 유형 인터페이스 매개 변수도 함께 전달합니다. 이것은 루트 또는 그 자식이 어떤 추가 데이터가 필요한지, 그리고 언제 주입 된 인터페이스에서 메소드를 호출하여 리턴되어야하는지 결정할 수있게합니다.

이 접근법은 테스트 가능한 고성능 코드를 제공하면서 집계 루트가 저장소 구현을 인식해서는 안되는 DDD 보안 주체를 준수합니다.