Sorting a list of aggregates based on associated aggregate's properties

Question

I am modelling a users management system, where users have a country of residence. I have modeled both User and Country as aggregate roots, and I am referencing the user's country by its ID internally.

The storage is a relational database and I have a UserRepository and a CountryRepository. Whenever I need the user's country, I am fetching it in an application service class (using the countryId from the user).

I am trying to get a sorted list of users, based on the country name.

The option that seems most "correct" would be to have a direct object reference to the country (instead of the countryId), and then sort the users list based on the name (which would be directly accessible by the user). However, to do that, I would have to have all users in memory every time, which seems insane.

I could use the DB and make the current UserRepository fetch a sorted list from the database, joining on the country, but I feel that this would stretch the responsibilities of the repo too much - digging into the internals of the Country in the underlying storage would introduce coupling.

So far, I have managed to avoid specific read models, but am wondering whether going in that direction would be the way to do it.

Any suggestions?

Answer 1

There are many things at play here, and by extension a few different approaches to relieving the tension you are describing.

The first discussion to be had is in regard to how you have modeled your domain. Obivously by changing your model, we may be able to provide more idiomatic solution to your problem. So ask yourself this, should Country be an entity at all? How often does a Country change, and what effects would such a change cause?

The first solution is to model Country as a value object. This can be accomplished in two ways: either by treating the current conceptualization as a value entirely or by partitioning your Country into two (or more) objects according to vectors of change. That is, have one country value object (CountryInfo) that holds the fields that will never change (e.g. name), and second country object (Country) that holds fields that do change (and thus behavior). This would allow any object in your domain to freely hold a reference to your country value object. I like this option the most.

The second discussion is one to which you alluded: separating the read and write models of your application. You are running up against exactly the kind of tension having a shared model can create. That is, you are beginning to consider compromising the design of your model (your business rules) in order to accommodate an orthogonal concern (likely a UI in this case). You didn't directly address this, but I doubt retrieving an ordered list of User has anything to do with a business rule. Because of this I would hesitate to include such logic in my domain.

With this in mind your second option would be to simply separate your write model from your read model. This can be as simple as allowing any ad-hoc read to be issued as necessary as a read has no chance of corrupting your domain. That is, you don't really need to model anything. Your entire read "model" can just be a database connection that returns arrays.

Your third option, again as you mentioned, is to simply provide for a query in your UserRepository that handles the semantics and ordering. There will be coupling no matter what you do because the problem you have been given requires that coupling, so I don't see much of an issue here. I find this to be a reasonable compromise for a combined read/write approach. I like this option second best.

And yet a fourth option is to simply store the Country.name along with it's id in each User entity. Again, because this value is unlikely to change, the downsides are few. That said, this option absolutely works against the ideals DDD and clean architecture would have us follow. Should your User business logic ever become dependent on a field for which it doesn't "own", your system would become susceptible to aberrant behavior. I like this option least.

Answer 2

Guiding principle

Your DDD model shall reflect the reality of the domain, independently of chosen the technology.

Note: You may chose the technology that best copes with the domain model, but you should not twist your design model for addressing implementation issues.

Design constraint

The DDD model and the usual architectural patterns should stay independent of the underlying database layer. This means that the same DDD-based design should hypothetically allow to change the persistence layer in the future.

Note: beyond DDD, all modern architectural principles such as the hexagonal architecture, the onion architecture, the clean architecture promote this principle.

Consequences

You should therefore design your application logic on the base of your domain model, without building on database-specific features. But the data source layer should still allow to make best use of the underlying technology:

• With an RDBMS, the most efficient solution of your sorting is only one JOIN away. But the repository pattern does not allow for different aggregates to be mixed, thus preventing the join.
• With a document store you would probably have to fetch two different documents exactly as you have described. But some document layout could facilitate navigation between related documents. And some querying tactics could optimise a particular sorting. In your specific example, knowing that Country is a much smaller collection than User, the query could iterated through a sorted set of Countries, and then query for the users in each country so that the sort is naturally done.

The key is to offer an API that fits the requirements but isolates the need for DB specific optimisations in the appropriate layer.

How ?

Building brute-force merging of entities into your application logic and do yourself what the database layer could do better is not a good solution.

The following tactics may get a more suitable and general solution:

• Enrich your repositories to give you the kind of extended sort that you need. The repository implementation could the use its knowledge of the underlying database to optimise. Inconvenience: it might get very painful to later migrate from RDBMS to document store, but now you’d get the full power of your RDBMS.
• If the sorting need is for only for specific reporting and not a general need, you could consider using query objects in order to avoid polluting your repository.
• You could use a “tactical model”: You would not change your DDD model, but you’d consider the country id and name as a value objects, only for the purpose of implementing the User repository: you'd nevertheless manage Country in the rest of the application (and in the db) as the true entity it is. (like having a view in an RDBMS)
• If you have many more of these needs, you could generalise the principle of the "tactical model" with CQRS (the query model being a kind of tactical model)