Query data across multiple repositories in DDD

Question

I am using multiple aggregate roots inside a DDD bounded context.

For example

public class OrderAggregate
{
    public int ID {get;set;}
    public string Order_Name {get;set;}
    public int Created_By_UserID {get;set;}
}

public class UserAggregate
{
    public int ID {get;set;}
    public string Username {get;set;}
    public string First_Name {get;set;}
    public string Last_Name {get;set;}
}

I am using SQL relational base to persists domain objects. Each aggregate root matches one repository.

In case I would like to find an order that was created by John Doe (seach accross multiple aggregates) what would be a DDD way to go?

add First_Name and Last_Name into OrderAggregate in order to add FindByUserFirstLastName method in OrderRespository, but that could raise data consistency issue between two aggregate roots
create a raw sql query and access DB directly in order to span search accross "repositories"
use "finders" in order to join entities directly from DB
replicate data necessary for query to be completed to a new aggregate root such as

public class QueryOrderAggregate
{
    public int ID { get; set; }
    public string Order_Name { get; set; }
    public int Created_By_UserID { get; set; }
    public string First_Name { get; set; }
    public string Last_Name { get; set; }
}

If you are sure (and only you can) that you have only one bounded context (with only one ubiquitous language boundary) then you should not model your aggregates (the write model) based on query requirements (the read model). So, in this case, without using CQRS, you should use option 2 or 3. — Constantin Galbenu
If you do use CQRS, then you just need to build a new read-model that contains all the information needed for the query, without using any joins — Constantin Galbenu

VoiceOfUnreason VoiceOfUnreason · Accepted Answer · 2017-07-07T15:35:01

In case I would like to find an order that was created by John Doe (seach accross multiple aggregates) what would be a DDD way to go?

Almost the same way that it goes with accessing an aggregate...

You create a Repository that provides a (whatever the name for this view/report is in your domain). It probably uses the UserId as the key to identify the report. In the implementation of the repository, the implementation can do whatever makes sense -- a SQL join is a reasonable starting point.

The View/Report is basically a value type; it is immutable, and can provide data, but doesn't not have any methods, or any direct access to the aggregate roots. For example, the view might include the OrderId, but to actually get at the order aggregate root you would have to invoke a method on that repository.

A view that spans multiple aggregates is perfectly acceptable, because you can't actually modify anything using the view. Changes to the underlying state still go through the aggregate roots, which provide the consistency guarantees.

The view is a representation of a stale snapshot of your data. Consumers should not be expecting it to magically update -- if you want something more recent, go back to the repository for a new copy.

Query data across multiple repositories in DDD

1 Answers