Comments on: Domain-Driven Pointcut Design

by: Jonas

Sat, 29 Apr 2006 03:31:14 +0000

Thanks Dean. I will definitely read your latest AOSD papers, sad that I missed your talks.

I think that your observation about the connection to the classic DIP and SDP principles is very true. Good point.

That is an interesting observation that I think is very true. Did we really think that we had to solve new problems?

Thanks for the comments.

by: Dean Wampler

Fri, 28 Apr 2006 15:12:58 +0000

Great post, Jonas. Your recommendations on the use of metadata and on avoiding fragile pointcuts are spot on. A couple of comments: First, the pointcuts in Contract4J fit this model exactly. In fact, it was the only way I could create a tool with truly generic pointcuts! I discussed this issue at length, along with emerging ideas about interface-based AO design in a few articles at aspectprogramming.com/papers. Second, the fragile nature of pointcuts that refer to specific details is an example of breaking the Dependency Inversion Principle (DIP) and the Stable Dependencies Principle (SDP), as described by Robert Martin (http://www.objectmentor.com/resources/articles/dip.pdf and http://www.objectmentor.com/resources/articles/stability.pdf).

by: Jonas

Tue, 25 Apr 2006 19:18:21 +0000

Alex, I agree that that would be useful. Could be an interesting excercise to build such a DSL upon the AspectJ PL, or even better to have the AJ PL extensible in some form.

by: Jonas

Tue, 25 Apr 2006 19:14:20 +0000

Geoffrey, there is definitely a need for signature based pointcut matching. However, I think that it can in many (most?) cases be avoided and that matching can be done using more high-level metadata information.

I do think (as I said in the article) that for example @Transactional, and other @AdviseMeHereWithFuncionalityX style metadata, is generally bad practice. But that it might make sense in constrained environments such as frameworks and containers. Matching on standardized annotations are usually a good thing.

by: Alex

Tue, 25 Apr 2006 15:31:38 +0000

This remember me someone asking us to implement in AspectWerkz support for call(@AccountStateChange), with no ..(..) at all inside - and possibly configure the weaver to only allow this kind of usage. It was a spanish guy at JavaHispano if I remember correctly. He explained that he would consider using AOP only if such a restriction could be enforced.

by: Geoffrey Wiseman

Tue, 25 Apr 2006 13:50:26 +0000

It seems as if you're suggesting this. There are some aspects that are implementation-driven in nature (e.g. transactional) and some that are business-driven (e.g. account state changing) and that the pointcut approach should match the advice.

Use business-oriented pointcuts (domain, ubiquitous language; @AccountStateChange) for business-oriented advice, and implemention pointcuts (@Transactional) for implementation advice.