The keyword in my statement is _operational_. Relational databases are excellent for analytics and reporting. But in an operational system with well-defined boundaries, it's more than likely that only portions of the larger system are required for any transactional behavior. In a modern architecture, you could simply write all transactions to an event store (write only) and use CQRS and a relational cache store for reads.
Another aspect of all of this is the misconception that we should design systems based on a relational data model. This only leads you through the whole impedance mismatch of ORM's and how you serialize/deserialize your bounded contexts or objects. We should not do this at all. We should design systems on those bound contexts and determine the data store accordingly. Operationally, a Document Database or Event Store is going to be the best tool.
We can fire change events at a data warehouse to store data in a relational manner for analytics and reporting, but none of that is necessary for our operational system.
In your operational system, if you need any sort of complex join, you've already created a poor design.
I will say this. This did not occur to me until I'd gone through the process of developing a complex system using Domain-Driven Design. Until you've done that, the old patterns will remain like concrete.
If I'm reading this correctly, then it's not relational databases/relational data models that are the problem, but instead the normalization across bounded contexts within a problem domain?
Partly yes. But it’s also the realization that we tend to start with an ERD or domain model before even looking at boundaries. We’re product-oriented. And vendors don’t help. Look at how hard everyone is pushing containers. Containers have uses, but there’s no rational explanation for the effort behind their marketing push.
Simpler is better. Boundaries need to be respected. Tools should be selected based on need, not desire.
Another aspect of all of this is the misconception that we should design systems based on a relational data model. This only leads you through the whole impedance mismatch of ORM's and how you serialize/deserialize your bounded contexts or objects. We should not do this at all. We should design systems on those bound contexts and determine the data store accordingly. Operationally, a Document Database or Event Store is going to be the best tool.
We can fire change events at a data warehouse to store data in a relational manner for analytics and reporting, but none of that is necessary for our operational system.
In your operational system, if you need any sort of complex join, you've already created a poor design.
I will say this. This did not occur to me until I'd gone through the process of developing a complex system using Domain-Driven Design. Until you've done that, the old patterns will remain like concrete.