Fachada de negócios

Qual seria a necessidade real dessa fachada? Não ficaria burocrático?

Pelo que entendo, seria para separar as camadas mesmo.

Controller
Negócio
Model
DAO

Do controller para o DAO, deve passar no negócio, ai pelo que entendo, tem que passar pela regra de negócio.

Uma Application Facade nada mais é do que um ponto de interação do mundo externo (view) com as funcionalidades da tua aplicação. Os métodos dessa classe geralmente fazem alusão direta aos casos de uso. É uma forma de reaproveitar o mesmo código de “regras de negócio compostas” por diversas views.

Vou usar um exemplo de um E-Commerce, a funcionalidade de fechar o pedido do carrinho. Já temos implementados a lógica para envio de email, para reserva de produto, cobrança, controle de estoque, etc., cada um encapsulado em um serviço diferente. A fachada ficaria mais ou menos assim:

public void fecharPedidoDoCarrinho(Carrinho carrinho) { // os limites do método são os limites da transação
    Pedido pedido = carrinho.finalizar();
    pedido.efetuarCobranca(servicoCobranca);
    pedido.reservarEstoque(servicoEstoque);
    pedido.enviarConfirmacaoAoUsuario(servicoEmail);
    // etc
}

A fachada parece um pouco com um Mediator, no sentido de que apenas orquestra uma transação, mas difere no sentido de que o Mediator isola completamente um componente do outro.

Tem uma cara de controller do MVC também, mas difere no fato de que o controller prepara os dados para a view e a fachada teoricamente é universal, para ser compartilhada entre controllers.

É uma camada a mais de abstração, que torna o software ainda mais complexo. Eu não acho que seja algo completamente necessário, mas depende do caso. É nessa Application Facade que vai aquela lógica de negócio que não cabe em nenhum outro lugar, esse agrupamento de instruções que caracterizam um caso de uso.