Interview: Adrian Colyer on Domain Specific Aspects

by Floyd Marinescu on Apr 09, 2007 |

AspectJ lead and AOP expert Adrian Colyer briefly discusses the concept of Domain Specific Aspects, AOP adoption in large enterprise, and using AOP to implement well known design patterns.

Watch Adrian Colyer on Domain Specific Aspects (11:24 min)

In the interview Adrian also discusses a phased approach for companies to start using aspects on their projects. At the first level you don't use Aspects in production but instead try it out in the development environment for design level assertions and testing. At the second level you use aspects for infrastructure type work, the "java.util" of the aspects world such as transactions, security, caching or polling. At the third level is using aspects for core business logic, such as business rules and policies.

Related Editorial

Impact of Java EE Frameworks on the Structural Quality of Applications

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

Enterprises Need Hybrid SSO Solutions to Bridge Internal IT and SaaS

Making the Shift from Relational to NoSQL

Why NoSQL - Three Trends Disrupting the Database Status Quo

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Using domain aspects by Rickard Öberg Posted

Re: Using domain aspects by Floyd Marinescu Posted

Re: Using domain aspects by Rickard Öberg Posted

When was the interview? by Twice Tshwenyane Posted

Re: When was the interview? by Floyd Marinescu Posted

Using domain aspects by Rickard Öberg

Great interview, and it's good to hear that there is more discussion around domain aspects. We've been using AOP and domain aspects since 2002, and have nothing but good experiences with it. Also, I must say that doing the opposite of what Adrian talks about, i.e. plunging into using AOP all-out instead of just using the "simple" parts, allowed us to exploit the advantages of it more fully, and in a less schizofrenic way. So there are certainly benefits to going "all in". But, at the same time it *IS* important to consider if a team have the skillz and experience needed to do so. With great advantages comes great risk, so it's (as usual) a tradeoff.

Re: Using domain aspects by Floyd Marinescu

Rickard, Adrian mentioned business policies that apply in a number of places as an example use of Aspects for domain logic. What were some of yours?

When was the interview? by Twice Tshwenyane

When was this interview carried out? Most of the things in the last paragraph seem dated.

Re: When was the interview? by Floyd Marinescu

It was about a year ago, we tried to edit out anything dated, sorry if we missed anything.

Re: Using domain aspects by Rickard Öberg

The majority of our interceptor aspects apply only to one "place" (=mixin), BUT the vast majority if mixins are reused in a number of places, which means that the interceptor aspects are then consequently ALSO reused in many objects. E.g. if I add a child to a container there's an interceptor which ensures that the child->container is properly set. The interceptor applies to only one place (=the Container.addChild method), but the Container mixin applies to some twenty places in our domain model. This allows for highly focused and specific aspects which are still highly reusable, when combined with mixins.

So the interceptors are usually very specific in terms of methods that they apply to, but those methods/mixins can then be reused quite a lot in a number of different classes.

The way I think about aspects changed quite a bit when I started using mixins in our domain model extensively, since as in the above case it allows the interceptor aspects to be very specific to a particular mixin, but the mixins are usually highly reusable.