I recently stumbled upon this opinion from 2016 saying that there is still case for domain logic in database.
I thought that this is totally obsolete. I am just wondering if the guy is still living in 90ties or this is can be really true. Set aside legacy systems.
What about having domain logic in database because of security requirements. Is that really a thing to do ?
Programmers nowadays seem to think very dogmatically, especially when they read the thoughts that other people write in their blogs.
Take Bob Martin's Clean Coding blog, for example. As a general observation, I find Bob Martin's writings quite clear and lucid, so it baffles me that people are constantly getting confused by the things he writes, such as the SOLID principles. They get hung up on what a "Single Responsibility" should be, or why some class violates Liskov's principles, when what they probably should be doing is simply to strive to write better code, and obtain some experience first, so that what they read in blogs has some context.
Basically what you're saying is that the database should contain tables and data, and that is all it should contain. But databases are uniquely suited to doing certain things that... well, databases are good at.
The article cites these things:
as suitable things for putting into the database. I happen to agree with him.
Reasons you don't put business logic (in general) into a database:
But these things generally only apply to those techniques, tools and training for which the database is not uniquely suited.
So, as with any other technique in software development, it depends. You evaluate your alternatives, and make your decision based on what you believe is the best possible course of action for your specific application.
The age of horse and buggy is over, yet you can still buy buggy whips.
Why? When cars are faster, cheaper to maintain, and neglecting them won't produce visits from the humane society, why is the horse and cart still around?
Because sometimes you have different reasons to do something besides the popular reasons.
What you should be learning is why domain logic in a database causes problems and what anyone could possibly get out of it. Then make up your own mind.
My personal view:
Domain logic is about behavior. Databases are about persistence, relationships, and, well, data. When you see it this way business rules shouldn't be in the database.
On the other hand who, said the database couldn't have behavior? I've built office databases using Filemaker. People call it a database but it's really a whole application development environment as well. Everything seamlessly integrated into one, and called a database.
Wizdom is usually found between extreme views. I've no doubt either could be made to work. When trying to find the middle it's tempting to just follow the herd. I will caution against it here.
A system that keeps domain logic in the database can work well. A system that keeps domain logic out of the database can work well. A system that mixes domain logic in both places is going to drive me batty. I won't know where to put new behavior. I won't be sure where to find old behavior.
If you still can't decide flip a coin and take its decision as gospel for any particular project. As far as I can tell that coin knows what's best as well as anyone else.
I had a case where solving it in the business layer would have been a real performance killer.
Our application OO security concept consists of roles AND groups. And both are recursive structures. We wrote a stored procedure that resolves the permission for a user on a domain object.
There are really less needs to fall back to database logic. But in this case I decided to go that way. But what you always have to consider: You give up abstraction. As soon as you have business logic in the database you have a hard day to change your persistence layer. So be very very careful.
