Re:Data-Oriented Architecture (2020)
by ChicagoDave on Thursday November 18, 2021 @09:05PM
(#29273014)
I used to think this way as well. Then I rebuilt the performance management system at Accenture using domain centric micro services and a document database. 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. No RDBMS-centric project I have ever worked on comes close to the efficiencies of what we did on that project and on projects since using the same paradigms.
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.
Re:Data-Oriented Architecture (2020)
by HelloNurse on Sunday November 28, 2021 @01:59PM
(#29371747)
> domain centric micro services and a document database
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?
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).