Getting all child entities of root entities?

Question

I am trying to reorganize my application from repository to entity into repository for each placeholder.

As a basic example, I have the root of the Cars entity. Cars have rental contracts. As far as I can see, contracts do not exist without cars, so cars are the aggregate root.

I am trying to implement a user view that will display every contract in the system (all children of the root objects). Before refactoring, I could just go to my contract repository and get everything. Since the contract store has been deleted (since it is not the root), I now need to pull all the cars from my repository and then get all their contracts.

My repository has an interface

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(); } 

I was thinking about creating an ICarManagementService and having a GetAllContracts method (possibly with filter options). Would it mean to get all the contracts I need to pull out all the car divisions with their contracts, and then get all the rental contracts associated with them and filter them out?

Then I can transfer this data to the controller and auto-negotiate the contracts, as before.

Is this the best practice?

thanks

Graeme

Answer 1

As far as I see, contracts do not exist without cars, therefore, cars are the aggregate root.

This is not necessarily the case. "Does not exist without" is not enough for the subject to become part of the Aggregate Root. Consider a classic order processing domain. You have an Order that is the aggregate root. You also have a Client, which is the aggregate root. An order cannot exist without a Customer, but this does not mean that Orders are part of a Customer Aggregate. In DDD objects within one aggregate, there may be links to other aggregated roots. From the DDD book :

Objects in AGGREGATE may contain references to other AGGREGATE roots.

An assembly is a life cycle and data exchange unit. This is essentially a cluster of objects that provides invariants. This is what you want to block if you have multiple users changing the domain at the same time.

Returning to your question, I understand that this domain is something like rent / lease a car / truck / limousine / bulldozer. I think that HireContract cannot be part of a collection of cars, because they can have different life cycles, and HireContract just makes sense on its own, without a car. This seems to be more related to the Order-Product relation, which is also a classic example of two different aggregates referring to each other. This theory is also supported by the fact that the business must see "All contracts." They probably don’t think of a Car containing all the Contracts. If so, how do you need to save your ContractRepository.

In an unrelated note, you might be interested to read this answer about repository interface design.

Answer 2

Separate the read / request concept from the write / command command, guided by CQRS, it is preferable to design the application by separating the read model, which consists of read requests and the write model, on the other hand, which consists of commands to execute certain logic on the domain model.

thus, querying all aggregate roots or creating custom queries to combine datasets is not a good candidate for a domain repository, but instead puts those queries in a readable repository (or better named Finders).

if you want to request a collection of objects in order to fulfill some domain logic, then this is an indicator that you need to separate from this collection and put in a composite root in order to encapsulate them and make a business operation or method to act on them.

check (http://moh-abed.com/2011/09/13/pure-old-ddd-with-a-twist-from-cqrs/) and (http://simon-says-architecture.com/2011 / 08/23 / repository)