In short, you should apply this business rule directly in your model. In your case, directly in the MonthlyRent getter and setter property. We all know how complicated that can get with lots of checks and security levels; so, that is what Specifications are for.
The DDD playbook introduces the concept of Specifications, for exactly this purpose of focusing the light on the model itself. You first setup your getter and setter like described above to get the functionality. Then, during your refactoring, look for making the model cleaner by abstracting the long getter/setter code into Specification classes.
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.");
}
Reading the code makes it very obvious to exactly what the code does. This is the core DDD concept in itself. Specifications should be kept very simple, and straight forward.
This code comes from Domain-Driven Design Quickly, a short and quick read for DDD quickly. It really is a short-n-sweet book on DDD that warrants a read over a few hours. Just 100 pages or so.