Respecto de las buenas prácticas, se me ocurren las siguientes ideas:
Quizás una pequeña mejora podría ser que, en lugar de crear las dependencias en el constructor, las recibas como parámetros. Luego, podrías definir una pequeña clase "factory" o un método de clase en UsuariosBLL para crear el objeto y sus dependencias. El último paso en este refactoring podría ser utilizar alguna herramienta de inyección de dependencias que haga esto automáticamente.
Por otro lado, la cantidad de dependencias DAL me dan como un "smell" aunque no estoy seguro sin conocer el modelo. Esa excesiva cantidad podría tener dos causas:
1) Quizás no estás utilizando el concepto de aggregate de DDD. En un aggregate (entre otras cosas) el ciclo de vida (creación, modificación, eliminación) es común para todos los objetos que lo component, entonces se requiere una sola DAL (repository in términos de DDD) para todo el aggregate.
Ejemplo (imaginando relaciones), si definís que quizás no necesitarías estos DAL:
_usuarioIdiomasDAL = new UsuarioIdiomasDAL();
_usuarioNaturalezaDAL = new UsuarioNaturalezaDAL();
_usuarioHabilitacionesDAL = new UsuarioHabilitacionesDAL();
_usuarioAsignacionesDAL = new UsuarioAsignacionesDAL();
_usuarioAsignacionHabilitacionesDAL = new UsuarioAsignacionHabilitacionesDAL();
_usuariosODSDAL = new UsuariosODSDAL();
... y podrías colocar esas operaciones en este DAL:
_usuariosDAL = new UsuariosDAL();
Lo mismo podría ser cierto para otros DALs, ya depende del dominio
2) Otra posible causa, aunque más difícil de responder sólo a partir de ese código, es que estés asignando responsabilidades que no pertenecen a UsuariosDAL, en cierta forma, justo lo opuesto al punto 1.
Saludos
----------------------------------
Carlos Peix
Móvil/Whatsapp: +54 911 4406 7571