Feature Driven Development

When modeling a recent application, we modeling the various roles people would play in the application as yellow Role objects. RoleA had behaviors that RoleA could perform, e.g., doA(), and RoleB had behaviors that it could perform, e.g., doB().

Now I am trying to design how to actually build the PD into a system, while also looking at the other layers needed in an application, more specifically, security.

I have been asking myself, "Does each yellow Role really become an object in the system?" My initial answer is "Yes", because we modeled it that way, but now I am thinking should there be a more fine grained permission set which can be split up into logical 'security roles' that would be assigned to a particular user in the application, and move the security to the UI layer, thus having the UI determine 'if (currentUser.hasPermission('doA')'.

I guess the question is "Where do you want your authorization interrogation to occur, the PD or the UI?" I am building a system that will allow for dynamic roles to be created, and then permissions assigned to them, thus granting users with the dynamic role access to certain features of the system. Building the security into the PD my be tying our hands a bit. Abstracting the security layer to the UI may be more appropriate in this case.

Does anyone have experience doing this or best practices for building a user configurable role/permission set within the PD, or should I abstract the security to the UI layer (which is now the direction I am leaning towards.)

Regards,
Eric