In a recent InfoQ article, Simplifying Enterprise Applications with Spring 2.0 and AspectJ, Adrian Coyler discusses the benefits of using Spring 2 with AspectJ to create modular enterprise applications. AspectJ, and an aspect-oriented flavor of Spring, Spring AOP, lets you incrementally apply AOP features to an enterprise application in areas such as factoring out cross-cutting concerns:

Starting out with AOP does not have to be an all-or-nothing big-bang approach. Adoption can proceed in phases, each phase bringing increasing benefit in return for increased exposure to the technology... The recommended adoption roadmap is to start out simply using the out-of-the-box aspects (such as transaction management) that Spring supplies. Many users of Spring will be doing this already, perhaps without appreciating that AOP is being used "under the covers". Following on from this, you can implement any custom crosscutting requirements you may have in the web, service, and data-access layers using Spring AOP.

The Spring AOP framework, however, supports only a subset of the aspect-oriented features of AspectJ, hence the focus of the article: Using those two tools together.

Spring AOP is a proxy-based runtime framework. There are no special tool or build requirements when using Spring AOP, thus Spring AOP is a very easy way to get started... A proxy-based framework is able to advise different instances of the same type independently. Contrast this to the type-based semantics of AspectJ where every instance of a type has the same behaviour. For a framework such as Spring, being able to advise individual objects (Spring beans) independently is an important requirement. On the downside, Spring AOP supports only a subset of AspectJ's capabilities: it is possible to advise the execution of methods on Spring beans, but nothing else.

The article then examines the various enterprise layers, and shows how Spring AOP and AspectJ affect different layers:

The service layer is typically the place where declarative enterprise services (such as transactions) are used. Declarative enterprise services such as transactions and security are great examples of requirements that impact many points in the application. In fact, even if you only wanted (say) transaction demarcation in a single place, it is still desirable to separate this function from your application logic to keep the code simpler and avoid unnecessary coupling. Since service objects are Spring-managed beans, Spring AOP is a natural fit to address requirements in this layer.

While Spring AOP can assist in the service layer, AspectJ provides more help in the domain layer, according to the article:

When it comes to requirements that impact multiple points in your domain model, the most important part of your application, Spring AOP is of much less assistance... AspectJ is a natural fit for implementing features that impact domain objects. AspectJ aspects don't need any special proxy creation, and can happily advise objects created at runtime either in your application code or by frameworks you may be using. AspectJ is also a very good solution when you want to modularise behaviour that cuts across all the different layers of your application, or that is in any way performance sensitive.

What's your experience in using AOP features in enterprise applications?