Alexandre,
na minha opinião a comunicação entre as camadas está errada.
Em um ambiente de serviços, as regras de negócio tendem a sofrer alterações até que se estabilizem. Contando com esta instabilidade, é necessário fornecer aos clientes destas regras um ponto único de entrada, uma interface comum para as funcionalidade / regras de negócio, para que alterações nesta camada não gerem alterações nas aplicações clientes que as utilizam (Baixo acoplamento - estabilidade dos assemblies relacionados).
Considerando que na sua arquitetura a camada BO armazena as regras de negócio, a camada Façade teria que representar este ponto de entrada para a regra de negócio, expondo métodos com base em serviços, agrupando então as chamadas para as regras de negócio relacionadas.
Façade > Business Objects > Dalc.
O controle de transação, quando feito via aplicação, teria que ser feito na camada Façade, para que um conjunto de regras de negócios relacionadas tenham um mesmo comportamento transacional.
Outro ponto interessante é manter os métodos das BOs o mais atômico possível. Cada método deve efetuar apenas uma tarefa bem definida. No seu exemplo, um método AtualizarEstoque da camada de negócio estaria executando a alteração de estoque a a atualização de movimento no estoque. Adaptando para o modelo que sugiro, a classe da regra de negócio implementaria um método exclusivo para cada função, se comunicando com a DALC e façade invocando os métodos. Neste modelo, conseguiriamos manter as classes sem alterações mas passíveis de extensão, uma vez que um método, quando implementado na regra de negócio, não sofreria alterações, já que sua função é única e bem definida.
Espero ter ajudado com alguma coisa.
Abraços.
