OTOH a lot of the abstractions are created because problems aren't solved coherently but rather partitioned into organizational structures adding incidental com

OTOH a lot of the abstractions are created because problems aren't solved coherently but rather partitioned into organizational structures adding incidental complexity. The worst are <noun>-services that seem to always do too much/too little or have interface designs that suit itself than needs of clients/consumers. I spend a fair amount of time decomplexifying the org out of architectures when we realize that performance sucks because reasons. We can do a lot of that discarding of excess by realizing that there's the data that's read, the rules applied, and the data that's written. Everything else is ephemeral and plumbing. Looking at a process that way, and seeing the amount of complexity/abstractions one can ask what all that really necessary? Does it pay for itself in some way? It has to justify its existence beyond implementing the needed process. I question the value of frameworks sometimes[0]. [0] https://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-http-upto-jdbc-as-a-picture/ https://ptrthomas.wordpress.com/2006/06/06/java-call-stack-f...