Simon is a hands-on software architect who works within 
[Twitter] simonbrown: Eating cream cakes in the sun at jersey zoo ... chillin'
[Coding the Architecture] Just a short note to plug a handful of sessions that Kevin and I are presenting at the upcoming Software Architect 2008 conference, 3rd-5th June, London. 1. Coding the Architecture : From Developer to Architect The first is a re-run of our ...
Thinking in aspects
AOP may be mainstream, but are people *thinking* in aspects yet?
AOP has proven itself as a very useful technique for centralising the cross-cutting concerns of an application and many of us use aspects in our day to day work, but are people thinking in aspects yet?
For example, frameworks like Spring use aspects under the covers to implement things like support for transactions, but effectively this is all hidden away from the developer. What I'm interested to know is whether people are explicitly designing aspects into their software. Based upon my own experience, I've not seen many instances where this has been done; where developers have made a concious decision to use aspects to solve a particular problem. Are your experiences the same?
Re: Thinking in aspects
Certain classes of problems align well to the AOP approach. An example from my past is a simple performance monitoring tool. I defined a pointcut that measured how long a method took to execute. I used Spring and AspectJ to add this around calls to the business service layer. This allowed basic method timings to be cleanly added without code changes to the api.
This was a textbook example (similar to logging which is often mentioned in AOP discussions) where AOP's cross-cutting approach fits neatly. The functionality applied across a whole logical layer of the application rather than a specific business requirement.
I agree though - finding the areas where aspects fit is tricky. Maybe they are intrinsically more suitable for tackling non-functional requirements. Audit is another strong fit with AOP for example.
Re: Thinking in aspects
The obvious examples to get everyone hooked are logging and performance monitoring: Code and configuration aren't too difficult and they save a lot of time and effort. Pre 2.0 Spring AOP helps by making it transparent how things are working: there's no "magic" involved.
The next step is to point at the ubiquitious gzip-filter and asking them to look at it as an example of AOP in the web layer (well, sort of...).
One area that benefits a lot from AOP is enterprise application integration. E.g., sending an e-mail in case of a certain event leads to clutter in your business code. Put it into in aspect and everything looks much cleaner.
IMO the tricky part for an architect is to get the "go" before having to implement code that really benefits from AOP.
Re: Thinking in aspects
I was looking for other areas where AOP might be appropriate but there really wasn't much more. To be honest the web app is a fairly straight-forward, simple web application, so maybe it's not a surprise that AOP isn't really necessary. On the other hand it's an example of exactly the sort of app we find everywhere, so maybe AOP isn't something that is essential to every-day programming.