How can domain modelling coexist with certain database optimisations?

Question

I'm currently working on a .NET project where we'd like to perform some computations directly on the database for efficiency (e.g. performing a join and count on the database to check if a user has permission to perform some action instead of retrieving the entity).

However, I'm not sure how this will interact with the domain modelling of the system, as from what I understand, the domain model is supposed to be independent of IO and other external systems. Should the domain model document/account for these queries to the DB, or is there a better way to do this?

Answer 1

Should the domain model document/account for these queries to the DB, or is there a better way to do this?

Real answer - it's fine.

There's no rule that says all of your domain code needs to be implemented in the same code, run in the same process, or located at a single host.

Udi Dahan frequently emphasizes the differences between logical and physical; you can have code that is logically part of your domain that is located at a different physical server.

It's not without its challenges, of course -- even in the database separating your domain code from "the plumbing" is a good idea, and the fact that you've got domain code running in your storage appliance means that you've got some extra architectural constraints, and those constraints may not be obvious -- so you'll want to have some architectural decision records that explain the real capabilities that you need from your storage appliance.

---

the domain model is supposed to be independent of IO and other external systems.

"Independent" might be misleading you.

I normally describe the separation this way: the domain model is concerned with representing the manipulation of information within the domain. But it isn't normally concerned with storage and transmission of that information.

In the ideal case, we can pick up the domain model, as is, and move it to host, and everything should still just work. For instance, if we take the domain model and move it from a command line tool to something accessed via a web interface, that doesn't change how the domain model itself manipulates information. Similarly, the domain rules don't change when we shift storage from one appliance to another.

aka: "Separation of concerns".

And yeah, sometimes it happens that we move our domain model (or part of our domain model) to a platform that doesn't support the current implementation of our model, and we have to rewrite.

Answer 2

Instead of answering how database optimizations can coexist with the domain model, I’ll tell you why you shouldn’t.

Eric Evans wrote the book ’Domain-Driven Design: Tackling Complexity in the Heart of Software’.

The Heart of Software is the domain model. That is where the complexity should be solved. The database on the other hand is a rather unimportant detail, we often need some mechanism to store the state of our domain, but that’s it. We don’t want the database to play an important role with regards to the domain model, because it would mean our business rules are now split in two places. Having several places where business rules live is increasing complexity, exactly what we are trying to prevent with DDD.

If you don’t actually have a performance issue, I would do the calculations in the domain model, to make it as explicit as possible.

If you do have an actual performance issue one of the tricks is to separate the data required to make decisions, from the actual decision making. Don’t ask the database if the user can perform an action, but supply the domain model with the necessary data to make the decision. This way you can still optimize the query in the database, but the business logic remains encapsulated in the domain model.