Aqui traduzi dois parágrafos do pequeno artigo postado por Adam Bien. Acredito que vale a pena refletir:
Algumas vezes você possui o banco de dados e os requisitos direcionados pelo cliente / patrocinador e principalmente pela UI (User Interface). Fazer um desacoplamento do banco de dados que você possui, neste cenário, não é benéfico. Contrariamente, o desacoplamento tornaria seu código mais complexo e mais difícil de manter. No caso de uma melhoria de funcionalidade, você terá que manter / melhorar a lógica de mapeamento, bem como tudo que estiver ao redor.
Em vez de esconder seus objetos de domínio atrás de uma Service Facade, você poderia derivar os objetos diretamente a partir do banco de dados (isto é, através de geração automática) e expor eles diretamente (ou seja, a própria referência) para a UI. A camada de apresentação (JSF, Wicket e outros frameworks centrados no servidor) poderiam até mesmo ligar os objetos persistentes declarativamente para os componentes UI.
A ideia defendida é diminuir a complexidade deixando de adicionar mais camadas (ou até removendo) em nossas aplicações. A cada camada sempre temos lógicas de mapeamento que apenas adicionam complexidade e muitos problemas para resolvermos.
Outro exemplo que me deparo é a camada dos objetos de acesso aos dados (DAOs). Não seria melhor manipularmos os nossos objetos de domínio diretamente? Possuímos ótimas ferramentas de mapeamento objeto-relacional, como o Hibernate e JPA. Será mais problemático utilizar o Session / EntityManager ou criar e manter mais uma camada sobre outra?
