4

내 응용 프로그램을 엔티티 별 저장소에서 집계 루트별로 리포지토리로 리팩토링하려고합니다.모든 집계 루트 엔터티 하위 엔터티를 가져 오는 중?

기본 예제에는 Cars의 엔티티 루트가 있습니다. 자동차는 고용 계약을 맺고 있습니다. 내가 볼 수있는 한, 자동차가 없으면 계약이 존재하지 않으므로 자동차는 집합 루트입니다.

시스템의 모든 계약 (루트 엔티티의 모든 하위 엔티티)을 표시하는 사용자보기를 구현하려고합니다. 리팩토링하기 전에 나는 단지 나의 계약 저장소에 가서 All을 얻을 수 있었다. 계약 저장소가 제거되었으므로 (이제는 루트가 아닌) 이제는 모든 자동차를 내 저장소에서 꺼내어 모든 계약서를 받아야합니다.

내 저장소 I는 ICarManagementService를 생성하고 (아마도 필터 파라미터)와 GetAllContracts 방법이 갖는 생각 인터페이스

public interface ICarRepository 
{ 
    IQueryable<Car> All { get; } 
    IQueryable<Car> AllIncluding(params Expression<Func<Car, object>>[] includeProperties); 
    Car Find(long id); 
    void InsertOrUpdate(Car car); 
    void Delete(long id); 
    void Save(); 
} 

있다. 그 계약을 통해 모든 자동차 엔티티를 꺼내고 각 엔티티와 관련된 고용 계약을 검색하여 필터링해야하는 모든 계약을 얻으시겠습니까?

그런 다음 이전과 같이 계약서를 컨트롤러에 전달하고 계약서를 자동 매핑 할 수 있습니다.

이 모범 사례입니까?

감사

그램

답변

4

자동차가 없으므로 계약이 존재하지 않는다는 것을 알기 때문에 자동차는 집계 루트입니다.

이것은 반드시 사실 일 필요는 없습니다. '존재하지 않는다'는 엔티티가 골재 루트의 일부가되기에 충분하지 않습니다. 고전적인 주문 처리 도메인을 고려하십시오. 집계 루트가있는 명령이 있습니다. 집계 루트 인 고객도 있습니다. 고객이없는 주문은 존재할 수 없지만 주문이 고객 집계의 일부임을 의미하지는 않습니다. 내부의 DDD 엔티티에서 다른 집계를 참조 할 수 있습니다. DDD book에서 : 집합 내에서

객체는 다른 AGGREGATE 뿌리에 대한 참조를 보유 할 수 있습니다.

총계는 수명주기 및 데이터 교환 단위입니다. 본질적으로 불변성을 강요하는 객체의 클러스터입니다. 여러 사용자가 동시에 도메인을 변경하는 경우 잠글 수 있습니다.

질문으로 돌아 가면, 도메인이 임대료/자동차/트럭/리무진/불도저 임대 같은 것입니다. 나는 HireContract가 다른 lifecycles를 가질 수도 있고 HireContract가 자동차 없이는 자체적으로 의미가 있기 때문에 Car aggregate의 일부가 아닐 수도 있다고 생각합니다. 서로를 참조하는 두 개의 서로 다른 집계의 고전적인 예인 Order-Product 관계의 것 같습니다. 이 이론은 또한 사업이 "모든 계약"을 볼 필요가 있다는 사실에 의해 확인됩니다. 아마 그들은 모든 계약을 담고있는 자동차를 생각하지 않을 것입니다. 이것이 사실이라면 ContractsRepository를 유지해야합니다.

관련없는 메모에서 저장소 인터페이스 디자인에 대해 answer을 읽는 것이 좋습니다.

+0

나는 사람들이 편집을 위해 "자동차"를 잠글 수 있기를 바랬다. 고용 계약서를 집계 할 수 있습니다. 사람들이 겹치는 고용 기간을 추가 할 수 없도록해야합니다. 고용자가 집계 된 경우에도이를 집행 할 수 있습니까? – GraemeMiller

+0

도메인에 대해 잘 이해하지 않고도이 질문에 대답하기가 어렵습니다. 그러나 나는 너에게 힌트를 줄 수있다. 우디 다한 (Udi Dahan)이나 그렉 영 (Greg Young)이 언급 한 방법은 컴퓨터없이 종이 기반 비즈니스에서이 기능을 구현하는 방법을 상상해보십시오. 이는 비동기 접근 방식으로 이어질 수 있습니다 (재고가 남아있는 경우에도 두 고객이 책을 주문할 수 있도록 아마존처럼 일시적으로 채용 기간을 허용 한 다음 이메일로 알려줍니다). "모든 것이 항상 100 % 일치해야합니다"라는 제한을 제거하면 많은 것을 얻을 수 있습니다. – Dmitry

+0

나중에 더 자세한 질문을 게시 할 가능성이 있습니다. 이번 주에 청서의 사본이 도착해야합니다. 좋은 DDD 연습에 대해 더 잘 이해할 수 있기를 바랍니다. 도와 주셔서 감사합니다. – GraemeMiller

2

별도 CQRS에 의해 인도로 쓰기/명령의 읽기/쿼리의 개념, 읽기 전용 쿼리와 구성 읽어 모델을 분리하여 응용 프로그램을 설계하는 것이 바람직하다 쓰기 모델은 도메인 모델에서 특정 로직을 실행하는 명령으로 구성됩니다.

이렇게 모든 집계 루트를 쿼리하거나 데이터 집합을 조인하기 위해 사용자 지정 쿼리를 만드는 것은 도메인 리포지토리의 좋은 후보가 아니며 이러한 쿼리를 읽기 리포지토리 (또는 더 정확하게 Finders)에 넣습니다.

일부 도메인 논리를 실행하기 위해 개체 컬렉션을 쿼리하려는 경우이 컬렉션을 추상화하여 집계 루트에 넣어야 캡슐화하고 비즈니스 작업을 수행해야합니다. 방법은 그들에 행동한다.

체크 아웃 (http://moh-abed.com/2011/09/13/pure-old-ddd-with-a-twist-from-cqrs/) 및 (http : // simon-says- architecture.com/2011/08/23/repository)

관련 문제