I've worked on a real-life product built using MyBatis, which you'd think is supposed to be best of both worlds - non connected DTOs, seamlessly filled out from

I've worked on a real-life product built using MyBatis, which you'd think is supposed to be best of both worlds - non connected DTOs, seamlessly filled out from SQL statements you write in the mapping configuration, etc etc. In practice the developers go overboard with SQL - the native-first SQL actually makes for quite confusing data model. There is value in clarity that limitations of Hibernate model brings or promotes. With MyBatis approach the underlying DB can contain incredibly bizarre joins, crazy FKs, you find aggregation functions in queries trip you up, massive views used under the hood, triggers make appearance to confuse you, the list just goes on. (The reason this happens is as years tick by, extra requirements get fitted into SQL model by doing these "clever hacks" and avoiding re-architecting. The kludges pile up, it's done because it's possible to do so, and every little decision seems like fair tradeoff when made in isolation. End result = massive pile of confusion.) You think staying close to SQL is the salvation, but really it's just another way to hang yourself. I will not argue it's possible to do excellent work, but in no way it's guaranteed.