DDD 다른 저장소에 대한 저장소 인식

Question

하나의 저장소가 다른 저장소에 액세스 할 수 있습니까? 이 경우 특히, 다른 집계 루트를 사용하여 추가 할 엔터티를 결정하는 하나의 집계 루트가 있습니다. 그것은 Item/Item Type 관계의 라인을 따라 떨어집니다. 항목 유형이 집합 루트 인 이유는 단일 항목의 범위를 벗어난 관리 도구 내에서 개별적으로 유지 관리 할 수 ​​있기 때문입니다.

문제가 발생하는 경우 리포지토리 팩토리 구현을 통해 리포지토리 인스턴스를 만들고 있으므로 구체적인 클래스 이름으로 직접 만들지는 않습니다. 집계자는 저장소를 인식 할 수 없습니다.

편집 - 자세한 내용은 :

구체적인 구현은 우리가 문서에 이미지를 첨부 할 수 있다는 것입니다. 문서의 이미지를 관리 할 수있을뿐만 아니라 다양한 유형의 이미지가 있습니다 (유형은 확장과 달리 구현 방법으로 정의됩니다). 문서 집계는 시스템에서 이러한 이미지를 사용하는 일부 개체 유형 중 하나이며 모두 동일한 유형을 사용하지는 않습니다. 우리가 도메인 서비스에 규칙을 첨부하는 동안, 이것은 특히 문서 집합체를 만드는 방향으로 조정됩니다. 집합체를 만들 때 특정 유형의 이미지 5 개와 다른 두 가지 유형 1 개가 있습니다. 개별적으로 목록에 저장되기 때문에 개별적으로 가져옵니다. 유효성 검사는 문제가 아니지만 문서를 어셈블 할 때 평가할 이미지의 유형을 제한합니다.

Answer 1

나는 그것이 당신의 노력과 관련이 있다고 생각합니다. 유효성 검사 단계 일 경우 (예 : 만료 된 항목 유형이있는 모든 항목을 삭제하는 경우) 서비스 계층 또는 사양에 속한다고 주장 할 수 있습니다. 사용하는 언어 (즉, 추가 할 엔터티를 결정)에서 후자를 제안하는 것처럼 보이지만 자세한 내용없이 말하기는 어렵습니다.

특정 관점에서 볼 때 아이템과 그 유형이 집합 루트로 간주 될 수 없기 때문에 (나는 결코 최고 DDD 순수한 것은 아닙니다.) 진짜 이유가 없다고 생각합니다. 예방 차원의 관리 콘솔을 제공하는 데 필요한 구현 세부 사항 만 제공합니다.

또 다른 관점에서 볼 때 두 개의 다른 컨텍스트가 작동하고 있음을 제안 할 수있는 집계 루트 사이에 흐림이 있음을 알 수 있습니다. 예를 들어, 관리 도구는 주 응용 프로그램에 별도의 경계 컨텍스트를 형성하므로 집계 루트가되는 항목 유형이 실제로 적용되지 않는다고 주장 할 수 있습니다. 예 : 주 도구가 항목 유형을 엔티티보다 더 많은 값 개체로 보는 반면 관리 도구는 항목 유형 (항목이없는 항목)에만 관심을 가질 수 있습니다.

업데이트

이 올바르게 유효한 엔티티를 조립할 수 팩토리 클래스의 책임 것 같아 문서를 조립 언급해야 (공장 이미지 유형의 저장소를 사용할 수 있습니다). 리포 지 토리는 엔티티를 구성하는 로직이 아닌 쿼리 및 추가 작업을 노출해야합니다 (내 눈으로는).