Ramnivas Laddad talks about domain aspects, how aspects fit in the design phase, how to model aspects in UML, how to enforce policies with Aspects, how he used Aspects to diagnose production problems including touch threading problems, and using aspects to simplify design pattern implementation.

One particular interesting use of Aspects Ramnivas mentions involved enforcing single-threaded use: <blockquote>I will give you an example that was my first serious aspect that really helped me solve some problems. I was working on a Swing based project and used to get some intermittent problems, you suspected that it was some threading related issues. You might be aware that Swing is a single-threaded library, that means you are not supposed to call Swing components from any thread other than dispatcher thread. So we had this problem which showed up only once in a while, and for some reason whenever we gave it to customers that problem would show up for sure. We did a couple reviews, and spotted some points, but not really anything that helped us. So I wrote a small aspect that said: "Make sure that whenever a UI component is updated the caller thread is in the dispatch thread, if it is not then report it". So we compiled our code with this aspect, and just used that code in the jar file for a few days, just normal usage. And at the end of the day we got a lot of output that told us all the places the violation was happening (and the callstacks). So we knew exactly why it happened. And that time if I remember correctly it was AspectJ .8 version. So obviously I did not want to put that code in production, it was not the right thing to do. So I basically implemented the correct code manually so Aspects helped me to enforce the policy of single threaded rule.</blockquote>

We use AOP for our entire domain model in our app. Currently we have 168 mixins that are used in various combinations in objects, and here are some examples:* ACL* Metadata* User info (matches user, group, container in LDAP)* Parent/child relationships (one for child, one for parent/container)* Icon and displayname (there are lots of different variants of this, for different objects)* File info* Site/Page/Layout/Portlet and other CMS-related mixins* Hit counter (also CMS related)and so on...

That was mixins. Then we also have 130+ interceptor style aspects that maintain various domain rules. Many are related to lifecycle management of aggregated objects (e.g. remove aggregated objects when owning object is removed), and many are related to maintaining various rules (e.g. if an object is added to a container, then the child->parent relationship must be properly updated). These interceptors are all specific to some few number of methods in some specific mixin (i.e. they are not widely applicable to many different mixins and methods), but they ARE heavily reused anyway since the mixins are reused in many domain objects.

We also sometimes use interceptor aspects to define method parameter validation rules, so that these are not hardcoded in the various methods and mixins.

On InfoQ.com's code base Alexandru Popescu used AspectJ to add things like discussion threads and the topic/tag categorization to content items at runtime. It's a nice implementation - domain objects (articles, videos, books) don't need to know about the discussion threads associated with them or how they are categorized, those get added in as introductions afterwards.

We can even do some cool things like havin articles and news posts announcing them share the same discussion threads.