Using databases without putting domain logic in them
In this article, Alex Kondov shares why it’s crucial not to store domain logic in databases while still utilizing them to their full extent.
He bases his argument on maintainability difficulties and threats to the separation of concerns, emphasizing the downside of splitting logic between the application and its storage. He also gives practical examples of improving the utilization of database capabilities without adding domain logic. One such case involves handling user reactions to data using application-level functionality rather than database triggers.
Kondov’s central point revolves around the importance of using databases as holders of information instead of decision-making tools.
Did you like this article? Then, keep learning:
- Explore asynchronous caching techniques in Laravel for better performance
- Understand PHP and Laravel debugging techniques relevant to databases
- Deepen understanding of database transaction management in Laravel
- Grasp how Laravel simplifies error handling in HTTP clients
- Learn why fast queries may not always be the best choice
- Improve Laravel codebase by applying architecture best practices
- Learn array validation in Laravel to ensure data integrity
- Explore Laravel's migration system critical for database schema changes
- Master efficient database querying using Laravel's where clauses
- Discover best practices for building RESTful APIs with Laravel
2 comments
Thank you for the informative post!
By the way, here are some cases of the 418 HTTP status code, few of them make sense… I think :D
The
PUT
method would be used to update the resource by passing the complete representation of the new state while thePATCH
method would require only a partial representation of the new state, i.e. if you need to update a few fields, you would provide only those few fields for the resource, I mean it would be only a convention