其实，你说的业务对象可以使用Domain Model实现，动作类我们一般用Componet Model如SLSB等Service实现。

如果在J2EE的范围内做一次正式的投票，我敢打赌Factory Method、Prototype、Singleton和Bridge绝对是在被淘汰之列，因为它们做的事情已经完全被支持Dependency Injection的容器包办了，程序员再也不需要知道这些模式。所以说呢，“Singleton是邪恶”的或者是一个非伪命题，不过更可能是一个伪问题，因为……谁还需要Singleton呢？你只需要PicoContainer或者Spring Core。 〈-
我比较，赞同这段话。另外，可能你对设计模式研究太深了，模式是什么？
难听点那是枷锁。你提到“如果我们采取面向Domain Model之后，很容易就会使用设计模式”我很少受那些模式的影响，那些模式我都自己曾经重构出来过。我看到你写的一些程序，受模式影响太深了，反而把程序写的没灵性了。有点为了用而用的嫌疑。若是，根据现在一些比较新的思想来看，完全没有必要那么办。不过，这也不能愿你，毕竟思想是发展的，你只能从gof中阴影中走来，也不能怪你会那么写拉。毕竟，你为我们后来者作出了不可磨灭的贡献，我想你的名字将会在中国的java史上留下的。我认为，下个同样美好和艰辛的时代，我们80年代的develpers的时代，定会在思想上彻底摆脱gof的影响，涅磐出自己的创新灵感和思想。

所以啊，面向表设计是因为现实的问题，但不是好方法，如果OOA或者MDA用的深入，一样能解决业务模型对象和关系型数据库的冲突。
而OOA或者MDA一定是趋势。呵呵，现在而言我觉得在自己的上下文(context)下，如果你觉得面向表设计能提高你解决问题的效率并且不带来其他麻烦的话，当然可以这样进行。
否则还是使用OOA或者MDA，特别是大的系统中。

nekesai说的经历感受大部分和我相同，其实我们都是从面向数据表分析设计转过来的，只要不断提示自己，挑战自己，这些很容易做到。

我觉得鲁中正气的思路代表目前大部分人的分析设计思路，很有代表性，下面言论不是针对鲁中正气个人的，因为我觉得鲁中正气是一个自信、刻苦、认真、好学的程序员，这些都是难能可贵的。

正如本文楼主提出的疑问：是什么造成了似是而非的面向对象系统？
1. 使用面向数据表分析 比较容易造成，注意不是一定会造成，如果不符合下列设计原则，那么造成概率就很高。
2. 不使用可扩展、解耦性良好的模式、框架。

正如我们前面分析，第一个条件不满足，那么第二个条件尚可支撑，但是如果不学习设计模式（不一定是GoF 设计模式）、不超越现有模式拘束，掌握分派、封装的要领，那么代码的面向对象性真是打大问号了。

所以，不管你使用如何高级的J2EE技术，用或不用EJB，如果下面两点不达到，你就很难保证你的系统是OO系统：
1. 面向模型分析
2. 使用良好的模式或框架。

当然，需要强调的是，面向模型分析MDA，我个人不非常看好自动化工具，虽然有句很极端地话：将来程序员消失，只有了建模专家，但是现实案例复杂，特别是中国国情的需求很复杂，所以，我极端地说：将来剩余两种职业：
1. 建模专家；
2. 框架设计师，他们负责把行业的通用性形成行业通用框架，具体项目只要装配，结合建模专家的分析设计具体项目的特殊功能即可。

有时写个预言觉得很过瘾。大放厥词还是很写意的事情啊。