DDD Políticas de Seguridad del usuario

Question

que tengo una clase RentalProperty que se ve algo como esto:

class RentalProperty 
{ 
    Money MonthlyRent; 
    List<MaintainenceCall> MaintainenceCalls; 
} 

Desde mi entender, el uso de DDD para cambiar la MonthlyRent, me gustaría tener la RentalProperty, cambie la propiedad MonthlyRent, y llamar a RentalPropertyRepository .Salvar(). El mismo proceso se manejaría para agregar un nuevo MaintainenceCall.

El problema que tengo es que, por ejemplo, un Handyman debería poder agregar un MaintainenceCall, pero no se le debe permitir cambiar el MonthlyRent. ¿Cómo debería implementar esta (y otras similares) políticas de seguridad?

Answer 1

AOP. PostSharp es muy hábil para cosas como esta.

Porque la seguridad es realmente una preocupación transversal.

Answer 2

En resumen, debe aplicar esta regla comercial directamente en su modelo. En su caso, directamente en la propiedad getter y setter MonthlyRent. Todos sabemos lo complicado que puede ser con muchos controles y niveles de seguridad; entonces, para eso están las especificaciones.

El libro de jugadas DDD presenta el concepto de Especificaciones, para exactamente este propósito de enfocar la luz en el modelo en sí. Primero configura su getter y setter como se describe arriba para obtener la funcionalidad. Luego, durante su refactorización, busque hacer el modelo más limpio abstrayendo el código getter/setter largo en las clases de especificación.

Employee employee = 
    employeeRepository.findEmployee(employeeID); 

Specification employeeCanModifyRent = new 
    Specification(
     new EmployeeHasAccessToManagement() 
     , new EmployeeHasAccessToMoney()); 

if(employeeCanModifyRent.isSatisfiedBy(employee)) 
{ 
    rentService.changeRent(); 
} 
else 
{ 
    throw new exception("Access denied."); 
} 

La lectura del código hace que sea muy obvio lo que hace exactamente el código. Este es el concepto central de DDD en sí mismo. Las especificaciones deben mantenerse muy simples y directas.

Este código proviene de Domain-Driven Design Quickly, una lectura corta y rápida para DDD rápidamente. Realmente es un libro corto y dulce sobre DDD que merece una lectura de unas pocas horas. Solo 100 páginas más o menos.