How to communicate between repositories

Question

As I understand, there is a 1-1 relation between a Repository and a AggregationRoot.

Suppose I have an AggregationRoot_A with an attribute holding an id for an AggregationRoot_B.

I will have Repository_A and Repository_B. Where do I handle a query that needs data from AggregationRoot_A object and AggregationRoot_B object?.

Getting all AggregationRoot_A objects and fetching one-by-one the AggregationRoot_B objects to process them is crazy, because the operation could be done with a simple join or whatever in the db side.

So, my question is, where can I handle operations that involve the data from 2 aggregation root related.

Choochoo

Answer 1

There is a 1-1 relation between a Repository and a AggregationRoot.

Yes

Where do I handle a query that needs data from AggregationRoot_A object and AggregationRoot_B object?

The current take on this is usually to bypass the domain model completely, and just query the database as efficiently as you can.

Recall, if you will, the early definition of aggregate (Evans, 2003)

An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes.

If we aren't trying to change the data, then we don't need the "aggregate" to ensure that changes are done correctly. We just need a way to take the information currently backing the aggregates, and transform that information into the report we want.

As a matter of technique, you might create a clear boundary between the infrastructure code that is coupled tightly to your data store and the application code which should not be. Such a facade might look a little bit like an aggregate. The key distinction would be that in this case, the facade has no affordances for changing the underlying data.

In other words, this facade might superficially look like a repository, but it will be missing a few key elements -- no ability to add new objects, nothing resembling a save, and no objects that support change.

When you are performing a query, you are working with immutable values, not mutable entities.

the response of this pseudo-repository should be an instance of some domain class? or it's just a plain object? Should I create an specific class for the items in this report query?

Any of those can be the right answer. In situations where you are just producing a report, a web page, an html document, it will often make sense to just copy the raw data into the final representation without messing about with ceremony. Horses for courses.

the response of this pseudo-repository should be an instance of some domain class? or it's just a plain object? Should I create an specific class for the items in this report query?

Well, what you are really trying to get out of the pseudo-repository is an in memory data structure that you can either (a) serialize as is, or (b) transform.

If what you are doing is preparing to send that information over the wire, then you likely want as little ceremony as you can get away with - if you can transform the record set directly into your on the wire representation of the information, perfect -- trying to move the information into and out of "objects" over and over probably isn't going to make it easier for you to maintain the code over time.

When you are using that information as an input to something else, you are more likely to want to enclose the information in some implementation of a role interface, so that the consumer isn't too tightly coupled to a data structure it doesn't care about.

Shorthorn

For the purpose in question: Is there any reason not to choose to implement a repository which would bypass the use of the aggregates by querying the persistence space (for ex. the database) directly and be part of the domain model? – Billetdoux

Repositories should be integration-tested. You need to be sure that your queries work well. Especially taking into account that there are usually a lot of weakly-typed transformations involved. Maybe even some dynamically constructed queries. That's why a repository should be focused on the DB integration solely. It should not be loaded with additional business logic like checking whether you should update the data or not. Whether the data for an update is valid. Whether a user has sufficient privileges, money balance and contract dates. Otherwise you maybe don't need DDD. – Beare

Thanks @Shorthorn and you guys. It's confusing to think that I have a GetAll, GetById, GetByWhatever, methods in the repository, and that is query stuff in my understanding. But now I have to create a pseudo repository to make cross-aggregationroot queries. Sorry if I'm misunderstanding. – Choochoo

And, the response of this pseudo-repository should be an instance of some domain class? or it's just a plain object? Should I create an specific class for the items in this report query? – Choochoo

If you just need the data for reading and then rendering as HTML or returning, e.g. JSON, you can create classes that fit your needs. It could be view-model class or a simple DTO (data transfer object) that you can directly send back in an API response. As long as you don't change any data you can query it and represent it in a way that best fits your requirements for reading and further processing it (e.g. for reporting or displaying). – Goodden