0

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?

Improve this question
  • Your app should be able to count just fine on its own. So what are these joins about? – candied_orange Nov 28 '20 at 6:10
  • You put such logic into domain services. – Andy Nov 28 '20 at 6:41
  • @candied_orange That's just an example so that I don't need to give added context. But the concept is just that there is some work that is being offloaded to the DB. – Arch2K Nov 28 '20 at 13:29
  • @Arch2K right, and I’m asking why? The DB has to run on hardware the same as your app. Why are you moving work to the DB? Don’t just say performance without justification. DBs aren’t magical. – candied_orange Nov 28 '20 at 15:05
  • @candied_orange I understand that DBs aren't magical, but for instance, if a user has multiple roles each of which has permissions, then it would be possible to use a SQL statement to check if a user has the permission to perform a certain action on a target without having to retrieve all the role entities and the details of the target. Besides, I was referring to the question in a more general sense, in terms of if optimisation led to some work being offloaded to outside of the domain. – Arch2K Nov 29 '20 at 16:14
3

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.

Improve this 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.