补充：
当然，不是完全使用DDD来设计就能提高性能，还需要依赖自己对缓存的掌握和灵活控制，我的建议是这样：简洁直接的业务建模+缓存优化。
呵呵,我也是做电信项目的,看了一下,发表一下自己的观点,电信项目的数据量大,表的数目也比较多,业务逻辑也比较复杂,如果用oo设计,对象之间的关联比较多,而且比较复杂,所以load一条数据非常慢,另外,需求变更比较频繁,往往在项目过程进行中需要进行表的改动,面向对象有可能需要重新设计对象之间的关系,维护起来不方便,而且在数据查询优化方面也利用不到数据库的优势,导致查询数度比较慢,个人观点是对象分析可以帮助我们深入了解对象与对象之间的关系,也就是表与表之间的关联,但实际开发中可能就需要将对象关系降低,而且用户只关心他需要的数据,就是视图,我不否认oo的优势,但实际开发另当别论,不要因为oo而oo,另外提一下,上次公司有个项目用hib,差点死掉.......(说的不对别骂哦,呵呵^_^)
这个世界上的软件并不永远只有CRUD这种操作，统计/分析/报表等等同样是必不可少的，如果捆绑上hibernate，就如j10a所说，绝对会在性能上走向死亡。
通常我会在项目中同时使用hibernate和jdbc，当然，会有自己的封装。
单纯做ORM，我倒是觉得itabis是个更好的选择。
我很认同banq。之前，有3、4个项目使用hibernate。问题很多，一是项目组没有非常熟悉hibernate组员，二是我们对业务领域根本没有分析，基本上是沿袭老思路，建库，创表，编代码。需求在不断变更，问题越来越多。
现在，这个项目，我们在业务领域分析方面，做了一点小工作，并且借鉴spring的思路，多在行为定义，行为组装上下功夫，尽量解耦行为与数据、行为与数据关系。应该说，比原先有所进步。我相信，随着项目组对hibernate的深入，对OO的深入，对业务领域分析的深入，我们的路会越来越清晰。
我也很认同banq的观念，因为从数据表建模的思路转变到对象建模思路，我也有过这样的经历，以前设计系统时都是从数据库建模开始，这样的问题是如果你采用对象的方式编码的话，很多问题都出来了，结果项目的代码也被改动的的很多，而且维护也很麻烦。现在我如果从头设计一个系统，我往往先是业务对象建模，业务对象先运行起来，在用代理模式或装饰模式给业务对象增加防问数据库的能力。这样代码改动量虽然没见得减少，但改动的范围缩小了，控制在几个类之间，而且便于维护。
捆绑上hibernate，就如j10a所说，绝对会在性能上走向死亡。
看怎么设计了,你是只单台server吧
不得不承认，web2.0时代已经来临，这个强调性能、敏捷的时代，hibernate会死的更早。呼唤一个崭新的框架! OO很重要，但过于强调就是“女人的裹脚布”了，又臭又长！
其实，没有必要争论是JDBC，HIBERNATE哪个效率高，哪个好，同样的问题不同人的解决结果也未必一样，有些人用JDBC写的SQL访问数据库未必比HIBERNATE快，所以人是关键・
几个月前，一次经历：由于设计问题，使客户一次操作产生几千条SQL，这样明显是设计问题，后来采用工具+DEBUG，拦截宋庆龄，看看是什么地方产生的问题，最后找出问题，把几千条变为几条，性能提高越30倍。
最夸张的是有个同事发了HIBERNATE产出的SQL让我查错，竟然是几页WORD的SQL，我没有能力找错误，这问题在什么地方，在设计！
所以用HIBERNATE，你是不是准备好了，公司的技术储备是不是可以，是不是已经从数据分析转道对象，领域分析了，是否清楚如何设计合理的对象关系，所以HIBERNATE只是O/R工具，他需要分析设计先行的基础！
彭先生，说的非常用理，只有你采用面向对象思想分析系统，重构系统，才能使Hibernate体现的淋漓尽致，如果你的系统还是采用数据库方式驱动设计，而不采用DDD设计，再怎么优化还是有问题，原因何在，原因出在现在大部分系统有人还是没能走出数据库驱动方式开发系统阴影，还是用面向对象的语言而不是思想开发系统，从而使系统本质上不是面向对象的．因此还是建议重构吧．
彭先生，说的非常用理，只有你采用面向对象思想分析系统，重构系统，才能使Hibernate体现的淋漓尽致，如果你的系统还是采用数据库方式驱动设计，而不采用DDD设计，再怎么优化还是有问题，原因何在，原因出在现在大部分系统有人还是没能走出数据库驱动方式开发系统阴影，还是用面向对象的语言而不是思想开发系统，从而使系统本质上不是面向对象的．因此还是建议重构吧．
我对hb不是很了解,正在学习中,简单说一下自己的想法:
系统开发过程中,问题来自多方面，比如说用了hb,查询性能下降很多，
可能会是多中原因造成的，比如，开发人员熟悉hb的程度够不够，能不能对HQL语句进行优化；对hb的长处和短处是否理解，知道什么情况下，使用hb的缓存会提高性能；
另外，还有设计的问题，对象的粒度是否合适，类和表怎样映射才更合理...
总之一句话，你对hb理解到什么程度，写出的程序的性能也会不同！
怎么让业务对象先运行起来呢？用代理模式或者装饰模式怎么就能让业务对象访问数据库了呢？我对这方面一直不解，希望得到解答，谢谢．
最近一篇谈lazy 的文章，提供参考：
Lazy Loading is Easy: Implementing a Rich Domain Model
http://today.java.net/pub/a/today/2006/07/13/lazy-loading-is-easy.html
其中有一句：
First off: why would you want to do lazy loading? The most important reason is to be able to have a clean domain model.
为什么你需要赖加载？最重要的是必须有一个干净的域模型Domain Model！这篇文章就是谈如何实现一个胖模型。
你把lazy设成true就可以,当lazy为false的时候,数据抓取会抓出一棵树,所以会很慢.把lazy设成 true以后你可以根据自己具体需要来抓数据,具体可参考hibernate手册的fetch语句.
>再请教个问题什么时候用hibernate呢 为什么我在这里的公司没有用呢
>是电信这样的大公司啊
使用Hibernate前提必须掌握领域建模的方法，也就是Evans DDD，至少了解类关联的意思和本质。
我们以前很多程序员都是基于数据表编程的思路，现在使用了Hibernate这样的ORM，Hibernate替代了数据表，或者说；插在了数据表和程序员之间，程序员就看不见数据表了，程序员必须学会和Hibernate代表的对象打交道，如果还是念念不忘数据表，那么每次用Hibernate，总是要转个弯，就不自然而且不方便。
换句话说：只有程序员真正掌握面向对象的分析设计和编程，才会觉得使用Hiberante等ORM工具是一个最简单的方式，否则，反而觉得数据表JDBC是一个简单的解决方式。
所以，可以从是否善用Hibernate看出程序员的OO素质。虽然你的单位是电信大单位，但是OO作为一个与面向过程全新的革命性技术和思想，它是挑战和颠覆面向过程的思维的，而我们国内以前大学教育以及实践如Delphi/VB等等都是传统的面向过程思维，虽然他们做过大项目，经验丰富，但是也吃了很多苦头，只是朴素地直觉认为程序要灵活，但是没有上升为OO理论，因为掌握OO是对自己过去经验和习惯的挑战，是对自己的挑战，又有几个人做到，象你这样舒服的大单位，谁有没事折磨自己，挑战自己呢？
这是一个经典的评论,如果可以评分的化应该使9+!
Hbm对于数据库的设计是以大挑战,善于使用o/r业务设计者,那张数据库表就和oo程序一样,从命名上就能看出来!
tss上有一篇文章,那个人的数据库设计真是夸张,可以文章找不到了,但是我就举几个名字给大家听!
hasHandleFactory,codingProxy,person,person.children,person.children.others