EssUP中的Aspect-Oriented/SOC

又看了一遍Ivar的演讲，感觉思路满新颖,下面是EssUP的基本原理Aspect-Oriented/Separation Of Concerns。编程中的Aspect和过程的Aspect的对比。


Aspect相互相对独立，可以叠加组合。
实践相互相对独立，可以叠加组合。

Aspect横切业务过程
实践跨越（横切）软件开发的整个生命周期

Aspect需要识别，方面可以组合
八大实践，就是八大方面

作为扩展的Aspect，不是必须
不需要所有的实践

Test is every Where，是一个方面的方面？

可以通过一个Aspect来扩展另外一个Aspect
其它实践来扩展核心实践框架

软件构架
过程构架

灌一小瓢水：
觉得Ivar就是善于搞这种形式上很漂亮的理论花架子。

我不这样看，这里面确实有料啊，熟悉AOP的同学会有同感吧？跳出来啊。。。。

Ivar提出一个理解现实的新理论,
可以用以解释很多现实现象,
但对改变现实却作用甚少.

我知道一些AOP。但只限于Java的Code Generated AOP。我要跳出来。给Partech老大捧场。

能不能举一些例子之类的？
另外，这个EssUP Aspect和Feature Driven有没有什么联系？

过程不再是“一锅汤”，而是呈现分离关注点的结构模式，很犀利的视角。

要解决问题，首先要认识问题，我隐约感觉EssUP可以做到这点。

各种不同的实践可以看作不同的方面，大多彼此独立，比如TDD,结对编程，重构，软件构架，团队建设，迭代等等，实践横切开发过程的整个生命周期（可以把它理解为一个程序里的过程对象）。也就是说开发过程的每个阶段都有可能会涉及到相同的实践。

对于扩展类型的Aspect,相同作用的Aspect可以相互替换，在包含插件的开发过程当中，实践也可以替换，比如：UseCase同UserStory。

可以写新的Aspect,可以开发新的实践，来扩展开发过程或者扩展某个实践。比如对于一个500人的开发队伍，Team的实践必须扩展。

分离这些实践，是为了更好的组织这些实践，这同分离Aspect的目的完全相同。

程序中使用Aspect，可以看作是很多切片不断叠加的效果，过程中使用实践，也可以看作是很多实践的叠加效果。


EssUP中的Aspect和Feature Driven，针对的主体不同，前者针对开发过程，后者针对业务领域。