同步自：http://www.blogjava.net/AndersLin/archive/2006/06/24/54806.html
在AOSD：应用AOP实现业务逻辑中， 我提出关注的接口；
其原文在javaeye上的讨论狼平方也提出可以用event，或者intercepter。
当然不同的方式可以解决不同的问题。这里要讨论一下AspectJ和Event以及intercepter的不同。
1. 先来看看event的方式：需要两个对象Event和EventHandler（EventListener），event和eventHandler，属于数据契约。换句话说，牺牲了编译检查的好处，当然可以应对变化时有一定的好处。一旦需求变化，代码上的变动需要的工作量不少，更为严重的是，如狼平方所说的侵入性太强。
2 接着看interceptor的AOP，相对于Event方式，虽然都是基于数据契约，都给自己做转型，但是代码量少了（因为代码生成），重要的是没有event那样的侵入性。
3. 狼平方做了改进，利用AOP来做brocastEvent的工作。需要做的工作还是很多，甚至我以为这个工作还不如直接用Interceptor来得直接。
如我在小议领域模型(Domain Model) 所说的Domain Service处理两个逻辑：业务规则和流程逻辑，而AOSD：应用AOP实现业务逻辑要试图解决的问题是流程上逻辑，而以上无论是那种方式，都无法解决一个问题：流程信息。
假定现有两个流程如下：
这里我们关注的目标方法是doSomeAction（），在doSomeAction中我们希望做些额外的工作，
以狼平方的例子，比如：financialService.createRequestOfMoney(...);
那么无论是用event：
还是interceptor：
我们注意到,这样做的结果是在bizProcessA()和bizProcessB()的不同业务流程都将导致执行
financialService.createRequestOfMoney
不过我们的流程逻辑要求是：
在bizProcessA()的流程下，执行financialService.createRequestOfMoney
而在bizProcessB的流程下，不执行financialService.createRequestOfMoney。
很明显无论是之上event，还是interceptor的AOP都无法解决这个问题。
面对这样的需求，就需要改进或者重构：
1. 最简单也最直接改doSomeAction(...)为doSomeAction(...boolean flag)。很明显这样的做法很不理想
2. 来点OO的， 将doSomeAction（...）分出去，作为一个接口，采用多态解决。不过依然需要解决动态加载问题，处理起来又需要费点手段。
真的只有这两个手段了吗？不！还有，那就是AspectJ
AspectJ提供了如下
within
withincode
withincode
cflow
cflowbelow
几个内置的pointcut，将可以做到我们要的效果，代码如下：
很显然，AspectJ提供了AOSD所需要的军火。
BTW：本文不针对狼平方同学，只是借由其两篇blog讨论开来，解释了AspectJ优点，以及为什么AspectJ是实现AOSD的最佳也是唯一军火。
事实上很多时候，解决问题的方法有很多，本文旨在阐明AOSD为我们提供了另一条思路。欢迎讨论和拍砖！
另补上我在javaeye讨论贴的完整例子代码，下载。