Arquitetura três camadas é um mito sobre desacoplamento...

Uma coisa que aprendemos desde nosso primeiro "if-else" em programação é que aplicações devem ser feitas em 3 camadas (ou mais), a saber: apresentação, aplicação e persistência. Uma arquitetura muito similar a ela é a popular MVC, que separa as coisas de forma parecida, mas a camada de persistência some dentro do "model" e a camada de aplicação é dividida entre "model" (com regras de negócio) e "controller" (que funciona como "cola" entre View e Model). Hoje em dia, boa parte das arquiteturas pra web é um misto de MVC com 3 camadas, num bororô formado por frameworks de apresentação, controllers temperados com "Dependency Injection" e um mapeador objeto-relacional. Tudo isso somado fornece o melhor nível de desacoplamento possível no sistema. É possível até mesmo trocar de banco de dados Oracle pra SQL-Server trocando apenas umas poucas linhas... Mas será que é desacoplado mesmo? Que tal experimentar o desacoplamento com uma alteração bastante comum como, vejamos... adicionar um campo? Bom, temos que mexer na view pra adicionar o campo, tb temos que mexer na camada de negócio para tratar o campo e validar, aí temos o transporte (V.O.s?) onde temos que adicionar o campo, e finalmente, adicionar no banco (o Hibernate até gera o campo pra vc, só que ele não migra os dados quando acontece a evolução do esquema, é na base da recriação da tabela). Okay, o que temos aqui? Uma simples alteração gerou uma "shotgun surgery" no código, necessitando de alterações em todas as camadas. Agora a questão é, como eu ISOLO isso? E, sendo mais cínico, de que me adianta trocar de banco com uma linha (e muito raramente eu faria isso), se para adicionar um simples campo eu preciso espalhar as alterações pra todo lado? Eu já vi a algum tempo atrás na web alguns artigos com a mesma preocupação, eles tinham até um nome pra isso, mas sinceramente não consigo me lembrar, e por consequência, não acho mais os artigos :( Se alguém achar, me dá um toque.