17 April 2007 - 21:28Business logic aspects

A while ago I made the case for business logic aspects, arguing that in a sense AOP is similar to SOA: you basically compose together an application by weaving business logic aspects where necessary. The example I gave was that of a taxing aspect that gets applied transparently to various financial operations so that when carrying out a financial operation you also tax it.
Pretty good in theory, and I still maintain the same opinion: if you can apply business logic concerns transparently thru AOP you should probably do it.
However, when watching this interview and this interview I realized that one big piece is missing from this picture: domain aspects modeling. The person in the first interview advocates using annotations for modeling aspects, approach that I don’t think scales pretty well. Aspect modeling is very crude for the time being (it is true that we are at the beginning of the adoption period for AOP so a lot of things are not in place) and this would imply that you cannot model complex aspects and complex interactions between aspects and advised classes. Pretty much all the business logic aspects I came across in different interviews are very crude and consist of very small operations, engaging the advised class in a very limited ways.
I guess this is only how far you can go ahead today. Tomorrow will probably be different, the case for business logic aspects grows and at one point the emerging complexity will have to be managed one way or another.

P.S. From what I read I see that annotations are widely used for creating pointcuts. This approach means that basically you are creating your pointcuts in Java code and not outside of it (in an AspectJ query or Spring config files) which is, to a certain degree, contrarian. I wonder if this is not related to the fact that currently you can manage your Java codebase a lot better than your spring.xml files or your AspectJ queries.