Business Requirements and Usage
The example application has the following business requirements:
Customizationthe system's functionality depends on users' identity. Users will subscribe for certain categories of stories and will be able to view them on demand.
Securitythe content will be available only to registered users.
Robustnessthe system will try to mimic the behavior of real production software with regard to reliability.
The typical usage scenario runs as follows:
A user hits the AspectNews Web site.
The application prompts the user with login information with an option to register unless the user is an existing customer.
The user either logs in or registers and is redirected to the start-up page.
From the start-up page the user can do one of the following: select news categories of interest, read news stories, or submit new news stories.
Although the application is somewhat simplistic from the functionality standpoint (this is on purposethis book is not about Web application development), the intent is to make it literally production ready, with all major concerns addressed. And concerns are plentiful: uniform exception handling and reporting strategies, general improvement of modularity using aspect-specific design patterns, synchronization policies, pooling of limited resources (such as, database connections), global performance optimizations using automatic buffering, security, and so on. Despite its simplicity, the application will have three distinctive subsystems to demonstrate the crosscutting nature of our concerns: presentation logic, persistence layer, and security system, which itself, in turn, will be implemented as a crosscutting concern (don't you love recursion?).