Data, Policy, Security, and Persistence

I'm entering a new world. I am reading "Agile Software Development" and learning about design patterns and test driven development.  What has occurred to me is that just about every Enterprise application has the same basic building blocks: UI, Data, Policy, Security, and Persistence. It is easy to see how to decouple the UI from the rest of the components, but after that things get hazy.

As I understand it, Data, Policy, and Security relate to the behavior of the application.  Persistence is the method of storage, and UI is the means of interacting with the application.  Data consists of the raw information being dealt with by the application; Policy defines the access and modification--the conditions under which the accessible data can be modified, and the range of modification. Security basically enables and disables elements of policy, in whole or in part.

Can anyone recommend a good "crash course" in how to elegantly decouple these components?  I'd like to design my next system so that I can modify security and persistence mediums without interfering with the Data and Policy components. How worried should I be about decoupling Data from Policy?  Does anyone have any good examples of decoupling Data and Policy?

Comments

No Comments

Leave a Comment

(required) 
(required) 
(optional)
(required)