|
|
|
|
|
|
by ragnese
1520 days ago
|
|
|
> My own solution was to keep no entity state in memory and translate everything into DB updates immediately. Use DB transactions where needed. You'll need another layer of code to abstract those higher-level DB operations so your domain code isn't littered with DB accesses, but apart from the extra lines-of-code the whole thing becomes very clean IMHO. Problem is, you won't find this solution described anywhere, and you are completely on your own. This is what I've settled on lately as well. I'm glad I'm not the only one. But, it's definitely not without its headaches. There are still domain entities/concepts, but they aren't always nicely centralized like in the typical examples of OOP DDD that choose to totally ignore/abstract persistence (and thus lead to bad performance, concurrency, etc). Let me give an example of one of my struggles in a current project. We have a SQL database with pretty normalized tables. Some of the data in our system can't be actually deleted for legal/bureaucratic reasons, but nevertheless, end users will still sometimes want to "delete" some widget from their view of the system. As far as the end user knows, the thing no longer exists. So we use a soft-delete boolean column on these tables. The struggle is that because our data is so normalized, we have to remember to account for soft-deleted rows of these tables all over the place. It's very easy to forget to filter your JOINs on rows that are "active" for one of these soft-deletable tables. I've tried my best to write some helpers to make it easier to build some of these queries without falling into a rabbit hole of writing my own DSL on top of SQL..., but it would be so much simpler and less bug-prone to do it the inefficient ORM-style way where we just define an object that is the equivalent of `SELECT *` from a bunch of tables, and have framework "magic" create giant graphs of all of these objects every time we need to do a query+update. |
|
|