Re:Data-Oriented Architecture (2020)
by twodave on Sunday November 14, 2021 @10:38AM
(#29217803)
I’ve seen multiple dev shops migrate from monolith to “microservices” without changing their data store, and the sad state that results is basically what this article is presenting as a positive. It’s anything but. It is incredibly difficult to reason about an application ecosystem using a shared data store. You’re basically just pushing all the complexity mentioned about microservices in the article into the database itself, except with fewer barriers. Any schema change now has to be verified against multiple (often an unknown number of) owners. Versioning is a much less fun problem in an RDBMS than in an HTTP application. Blurry data boundaries eventually cause enough confusion and poor decisions that you may as well be back to running a monolith since you end up having to scale all your pieces together anyway.
[ Parent
| on HN ]
I've also seen it happen more than often than I wish, but the issue in this case is more about skipping a common data access layer rather than usage of a shared data store. This would have been a problem in any system: even in a monolithic application, such lack of proper layer (and proper checks and verifications around data access) will always cause these issues.
I'm not sure if it's the answer but you may be slightly misunderstanding it - you are describing a system without the crucial "Data Access Layer" which sits in front of the database. This layer is what mitigates part of the problem you are describing because it puts a layer of abstraction b/w raw data access and the services using the data. For example it could be a REST API, or using a message queuing backbone or both.
Re:Data-Oriented Architecture (2020)
by hyperpallium2 on Sunday November 14, 2021 @06:31PM
(#29221798)
Maintaining access for old programs despite evolved schema by was Codd's motivation for relational algebra.