今天被问及了一个问题：请说说AOP和SOA。
我的理解是他们全部起源于“封装”的思想，注重于业务功能和实现的分离，所以从根本上说他们没有什么区别。他们现实中区别在于分别注重于解决不同层面的问题，可以说是“封装”这个接口的不同实现。继续说起来其实IOC/DAO也是一样的道理，全部的思想核心都是封装，让每一个操作节点都可以全神贯注在自己特定的业务过程中。
这个答案被对方当时否定了，但是也没有给出他的理解，限于当时的情况我不方便追问了。特此拿出来大家讨论一下，听听更多人的意见。
封装是OO的一个大思想，这些都是OO下面具体一些做法，当然遵循封装这个总原则。
已经很多。AOP是软件开发方面的思想，而SOA是一个更高的架构，是软件整合 异构系统协同运行等方面的。两者风马不相及。
IOC是解决对象依赖的一种模式，而DAO是解决对象持久化的一种模式，两者也不相关。
可以查查本站 标签列表 中有关AOP和SOA IOC DAO讨论，
所以这些概念全部都是一个“封装”思想下面对各种实际问题的解决方案了，是同根的。
OO把对象引进软件里，AOP是对OO的补充，一个方法里特殊的执行代码总是要执行，但是放置的位置就不一定非要放在这个方法里，跟这个方法关系不大的就应该拿出来，不单是从方法里拿出来，也要从类里拿出来，并且拿到新的类里，新的类和原有类不存在代码上的依赖关系，有了AOP就方便得多了，这些特殊的代码会被当做单独的部分来处理，典型的就是日志。这算是面向方面的封装
IoC，注入实例，依赖接口，接口本身就是封装实现的体现，这没什么好说的。另有实例查找也不错。
Dao数据访问对象，封装了数据访问方式，在dao之上应该看不到数据源等。
SOA，不要所有东西都共用一个模式，正视异构系统共存的现状，别推倒重来，能利用就利用。我不认为这是封装的一种体现，封装是从设计开始就体现出来了，而SOA是达到大规模后，看似各部分被封装起来，实际这并不是从开始就被特意设计成这样的，这是整合后的结果，是形式上封装。
AOP：
对于AOP我认为他最大的意义是开始了一个新的软件集成方向，从编程转变为组装，从此开始用户有机会在完全脱离程序的情况下组件一个符合自己需要的业务过程。
在配置的过程中修改的是系统组成配置而非一个程序的执行选项，这样的任务更适合由一个领域专家而非程序员来完成。在充足组件的支持下一个领域专家有机会为他的客户配置出一个专有的业务过程，而在这个过程中并不需要一个程序员的支持。
现有的AOP方式还不足以支撑这样的方式他的思维高度还不够，但软件应该是在这个方向上发展的，软件只是一个基础应用为王。
SOA:
SOA的视觉高度是在AOP之上的他在思考服务的提供方式，服务必然是一种整合可以是一个或者一系列业务过程的整合结果。
但是他有一个前提条案件那就是旗下的业务过程“可以被整合”，只有一个能够真切的描述实际业务需要的“过程”才能够被良好的整合起来（这时候就不再关心这种描述方法本身了）。这个“过程”在实现的时候可能不会是直指整体的业务整合需求，但是他的设计者必然能够从更高的视角来看待自己需要实现的内容，只有从整体的角度上进行的局部设计才有可能被完美的融合到整体中。
SOA的实现过程可能是自底向上的，但是其中内在的自然过程必然是自顶向下的，把一个大脚车的轮胎装到一辆F1车身上显然除了娱乐没有更现实的意义。所以在比赛中每一个被安装到f1车身上的轮胎必然是从设计开始就在思考“我如何服务于F1的比赛过程”，其中的内涵已经远远超过了通常对于轮胎的行驶要求。
AOP是在封装操作过程，SOA是在封装业务过程，他们都是对于操作方法的指导。