Miért lenne bonyolult? Nem attól bonyolult valami, hogy sok osztályod van, hanem akkor, ha nem tiszták a szerepkörök: ki kivel van, melyik osztály mit (rossz esetben: miket) reprezentál.
"Pl. egy adatbázis köré épített rendszernél (legyen mondjuk myBatis, vagy JOOQ, hogy a JPA-s önszívatást elkerüljük) teljesen világos, hogy ami osztályom van, az egy-egy sort reprezentál az adatbázisban, és pont."
"Maga az üzleti logika is adatbázis sorokból képzett objektumokon dolgozik."
Nem, az üzleti logika üzleti objektumokon dolgozik, attól teljesen függetlenül, hogy ezek hogyan vannak perzisztálva. Kivétel, ahol maga az adatbázissor az üzleti objektum, de ez csak maguknál az adatbáziskezelőknél van így.
" a valóság pedig az, hogy az adatbáziskezelőt a legritkább esetben kell változtatni."
Azért kell a legritkább esetben változtatni, mert ha a DB köré építed a rendszeredet (és általában sajnos így van), és a business megkérdezi, hogy mennyibe kerülni áttérni Oracle-ről MSSQL-re, és mondasz neki egy vállalhatatlanul sokba kerülő és sokáig tartó DB-cserét, akkor inkább úgy dönt, hogy nem változtat a DB-n.
Mint amikor egy szar frameworkbe vagy belekényszerítve, mert a project elején hoztatok egy rossz döntést, amit kijavítani kurva sokba kerülne, ezért midnenki úgy dönt, hogy marad a szar.
Ez a fajta szemlélet (a DB köré építünk mindent) eredményezi, hogy a DB-t nem cserélgetik: mert az alkalmazás nem engedi meg, hogy cseréljék a DB-t. Pedig sok esetben jó lenne upgradelni, vagy olcsóbb DBMS_re váltani, mert megváltozott a licencelés stb. De nem, nem lehet. És az IBM, az Oracle és sok cég ezért keresi magát halálra: mert ők azt akarják, hogy az ő szoftvere köré építsd a tiedet, ezért függj tőlük. És a cég meg a szoftver élettartamáig fizeti a licenceket, mert nem tehet mást: elbaszták az architektúrát, és megfizetik az árát.
Az egyszerű debugolhatóság pedig ott egy fals feltételezés, hogy nem debugolhatóságra tervezünk, hanem egyszerű módosításra. Az, hogy ez complex mintákkal jár együtt (factory, interfészek stb), az az ára az egyszerű módosításnak. Hány olyan kódod van, amit baromi sok idő lenne rendesen refactorálni, csak mert azt feltételezted, hogy "ez így van jól, hiszen sosem fog változni a rendszer". Aztán kiderül: a szoftvernél az igények nagyon gyorsan változnak. Épp ezért könnyű módosíthatóságra tervezünk (forward-compatible architecture).