So it's easy to succumb to temptation and take the easy path (I don't want to add three tables to keep it normalized... let's allow this column to be null, the applications can check... another field for the second phone number, we'll see about the third one... make your queries non-isolated or we could have a deadlock...) with apparently good results, and then when technical debt comes home the architecture amateurs can blame the tools instead of themselves.
I've seen this way too many times to back off of my assessment. Relational models do not, in the long term, enable an agile business model. It is an anti-pattern even if it takes years to reveal itself as such.
The problem always lies on excessive abstractions and patterns on the backend side. Which really isn't solved anywhere by any strategy other than keeping things damn simple.
Your descriptions of "impedance mismatch when converting relational models to business models" and "automating mappers that leads to a hardened and immovable design" are a precise example of that: OOP patterns muddying the development process and causing problems in unrelated parts of the system (in this case the database).
Of course, keeping things simple and programming in a way that fits the relational model is incredibly difficult for developers that have been trained to believe that complexity is the answer to all problems future and past. So the resort for those people is to keep pestering management to throw the baby (relational databases) with the bathwater (relational mappers and other related OOP patterns).
And when people needed the transactional data in a relational model, we streamed events and that was read only in some other tool and the core system didn't need to know about any of that.
Been down this road. Saw a fork in 2015 and haven't looked back.
It sounds like you put ORM hell behind you by getting rid more of objects than of databases.
> Not only were we able to build faster (schemaless is so much easier on change management), but also offers the ability to add features at a frighteningly fast pace
What kind of change management? Frightening clients with API changes? Eluding code reviews and formal release processes?
I didn't say relational databases are bad. I said it was an anti-pattern. In my mind, relational databases should be mostly used in data warehouses, reporting, and analytical systems.
Transactional systems are better suited to document databases and CQRS.
This is such an inflammatory and ignorant statement that I don't really have any other answer other than to call it pure bullshit. Relational Databases are probably one of the few popular areas of our profession that are not only backed by formalisms and research that tell us to do it correctly, it is also proven to work in practice: it is the de facto backbone of most financial, commercial, government systems and, heck, even military, but also even of modern FAANG-style big tech.
Sure, they're boring. And it takes time to learn. And normalisation might has its costs but we can know them all upfront, and we know where and how to break them. The (currently trendy) horizontal scalability is indeed non-trivial with them, but vertical and horizontal-via-sharding are easier than most ad-hoc solutions. But the boredom pays off in guarantees, and to learn you have 50 years of mature material to rely on.
(This is not to say that non-relational databases are useless. Both have its uses, but they're both only really useful if you properly understand them)
Complex enterprise systems are complex for reasons beyond the technology. Often due to processes and bureaucracies. Those complexities often end up turning into "essential complexity" in systems, and Domain Driven Design is not able to reduce such essential complexity, and nothing can.
Nor is Domain Driven Design incompatible with relational databases, especially the tactical part, which is often the major selling point of DDD. It is entirely possible to model domains within databases, and is entirely common.
Also, DDD is not a guarantee of success. If anything, it has not proven itself nowhere near as much relational databases have. As much as the original idea of DDD is good (again, especially the tactical part), it I see it often become rationalisation for the same old architecture astronautics that cause excessive incidental complexity. For people wanting architectural complexity, I can completely understand the distaste for something simple like "keeping it in the DB". It completely negates all the fancy technical patterns prized by developers. This is not to discount the original idea and techniques of DDD: merely saying that the excuse "relational databases can be bad if not well done" applies as often, if not more, to the practice of DDD.