2009-03-09 8 views
5

Mam klasy RentalProperty który wygląda mniej więcej tak:DDD Zasady zabezpieczeń użytkownika

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

Z mojego zrozumienia, używając DDD zmienić MonthlyRent, chciałbym uzyskać RentalProperty, zmienić właściwość MonthlyRent i wywołać RentalPropertyRepository .Zapisać(). Ten sam proces zostanie obsłużony w celu dodania nowej funkcji MaintainenceCall.

Mam problem jest to, że na przykład, rączka powinna móc dodać MaintainenceCall, ale nie powinno być dozwolone, aby zmienić MonthlyRent. Jak powinienem wdrożyć tę (jak również inne podobne) zasady bezpieczeństwa?

+0

Może ja naprawdę zadaje to samo pytanie fundamentalne, jak wy, ale ja zacząłem od wyruszą w innym kierunku pierwszego. http://stackoverflow.com/questions/5374176/can-ddd-repositories-be-aware-of-user-context – jpierson

Odpowiedz

2

AOP. PostSharp jest naprawdę sprytny na takie rzeczy.

Ponieważ bezpieczeństwo jest naprawdę problemem przekrojowym.

+0

Ciekawe, jak ja zostały wresting tę koncepcję, jak również. +1 – eduncan911

+1

bezpieczeństwo nie jest tak wyraźnie przekrojowej troska jako coś podobnego logowania. Jeśli chodzi o rejestrowanie, jedyną rzeczą, która różni się między jednostkami, jest to, co jest rejestrowane. To, czy użytkownik jest uprawniony do działania, może zależeć od konkretnych informacji w domenie. –

8

Krótko mówiąc, należy zastosować tę regułę biznesową bezpośrednio w swoim modelu. W twoim przypadku bezpośrednio w właściwości MonthlyRent getter and setter. Wszyscy wiemy, jak skomplikowane może się to stać dzięki wielu kontrolom i poziomom bezpieczeństwa; więc do tego właśnie służą specyfikacje.

DDD PlayBook wprowadza pojęcie specyfikacji, dokładnie tego celu skupienie światła na samym modelu. Najpierw skonfiguruj getter i seter, jak opisano powyżej, aby uzyskać funkcjonalność. Następnie, podczas refaktoryzacji, poszukaj modelu czyszczącego, poprzez wyodrębnienie długiego kodu gettera/setera do klas Specyfikacji.

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."); 
} 

Odczytanie kodu sprawia, że ​​dokładnie to, co robi kod. Jest to podstawowa koncepcja DDD sama w sobie. Specyfikacje powinny być bardzo proste i proste. Ten kod pochodzi z Domain-Driven Design Quickly, krótki i szybki odczyt dla DDD szybko. To naprawdę krótka, słodka książka na temat DDD, która gwarantuje czytanie w ciągu kilku godzin. Tylko około 100 stron.