i share your sentiments. i think what you are describing are symptoms of the unfortunate reality we see everywhere today: design-by-buzzword. when the choice of platforms or architecture has political motivations, there is not much we can do. but to choose a framework, or API, or architecture mostly because it is the latest design fad is, to put it lightly, shameful. and the reality is, many choices in frameworks are made without fully realizing and understanding the implications. one might as well flip a coin to decide, or choose blindfolded because without fully understanding, the decision is arbitrary. this is the “mismatch” in architecture and needs. these general-purpose APIs and frameworks all promise the world, but they are only useful in a very narrow (or prototypical) slice of a domain problem scenario. and of course, when it is applied to your scenario you eventually realize you’re in black box hell. the elegant and clean code that you began with has slowly but surely yielded to necessity, scope creep, bandaid-ing, configuration acrobatics, and just POSO (plain old spaghetti objects). this is the poisoning you referred to and this is how a project dies. it’s sad, because everyone can see this (i hope), but it is too late, and there is no time to save it. if there is one thing that every architect should feel when an architectural layer/framework/API like Hibernate is added to the project, it should be fear. be very, very, very afraid.