如果OO永远占统治地位下去，那才是个恶梦。
从下面这个案例可以看出，面向数据库分析并不完整，不能提供我们接近未知新系统的本质，这不是一个好的方法论：
http://www.jdon.com/jive/thread.jsp?forum=62&thread=23720
j2ee的ejb能做到很好的数据缓存，数据库时代的终结，但并不是说就不用数据库了，banq也没这个意思，只不过说是设计的重点的转移。要做好一个系统的设计不简单，松耦合，多层次，才是好扩展，好理解的系统。系统的成功可能性才会大。
http://www.aw-bc.com/catalog/academic/product/0,4096,032111230X-PRE,00.html
翻译大意资料：
这是来自实战的一本书，我们希望节省你在软件开发中的大量时间和精力，它给你一系列的archetype patterns 和原理，在以后时间内，我们希望发布一系列有效的archetype patterns。
Archetype patterns原型模式是一个高价值模型组件，你能够容易在UML建模使用它们，每个原型模式提供了可理解的业务建模解决方案。这些模式是高价值而且相似的，但是不太成熟，一些模式被$300,000标价，原文：These patterns are valuable―a similar, but much less mature, set of patterns was recently independently valued at about $300,000 by a blue chip company.
使用这之中任何一个模式，甚至模式的片断，也许会节约你几天甚至几个月的工作时间，甚至更重要的是：这些模式也许阻止你付出昂贵的错误探索代价!
在2003年我们开始考虑，我们在一个软件革命的开始，它象90年代我们看到的面向对象编程从传统过程语言中抽象出来一样。
我们相信我们看到的是以后这十年，更有意义的抽象级别的发展，这将是一个以代码为中心的软件开发方式的根本改变，这就是通过 OMG’s Model Driven Architecture (MDA).
我们希望这些概念和技术或工具以及模式能够帮助我们将这软件革命变成现实。
为什么这样说，下面帖子给你原因：
俺对这篇文章的理解是设计的重点从数据库设计中脱离出来。
俺之前参加一个电信项目，也是以数据库设计思路开始的，虽然当时已经对UML分析设计了解了一些。
OO的分析方法，也并没有抛弃数据库，我们从对象模型可以知道导出数据库模型。
我认为企业软件基本可以认为由表现层、业务层、持久层构成。中间件根据我的理解就是提供一些通用的功能调用，从而可以从琐细的底层API中解放出来。不知道这样的理解对不对？
bang的方案比较偏激，我不知道你是如何实现持久化的，我也不知道这种框架对集群分布是不是很合理（数据的复制和同步应该比对象的复制和同步效率要高的多）。
我也不知道在这种框架下，数据的集合运算是怎么实现的，是不是又要回到原来的网络型数据库上去。
同样我也不知道如果业务对象出现了更改，怎么从原来的持久数据过渡到新的业务模型上来。（这是所以要从文件进化到数据库的重要原因）。
另外我也不知道如何解决并发查询和修改。（我知道可以做到但是需要付出如此巨大的努力重新实现在数据库里已经解决了的经过无数次考验的实现吗？）
bang好像也没有真正回答了海量数据时，超过了内存限制时能够怎么办。
另外，单独实现从数据库到业务对象的映象层好像也不能说就是不符合OO的。持久化本来就有很多方式，包括门面，包括OR映射，包括数据集。好像不能说这些都不是OO设计吧。
在数据库上增加了映射层后，解耦了数据和业务对象，并不能否认继续优化数据库的必要性，也不能得出不需要数据库设计的结论吧。（其实bang在后续的讨论中还是间接的承认了还是需要数据库的，只是不需要数据库设计和优化了。）
我来量化数据库和业务建模的对比。
在过去，包括Jsp+javaBeans时代，我们虽然使用J2EE，实际上还是严重依赖数据库的，你看看我们当初的JavaBeans都是用来操作数据库的，其实那也是一个两层结构。
后来EJB出现，专门通过实体Bean隔离数据库，这样业务层只和实体Bean打交道，无需直接和数据库交互，而且可以不知道数据库的类型，管你MySQL或Oracle呢。后来出现Spring/Hibernate其实是这个中间件模型的简化。
与此同时，UML等大量建模分析设计方法出现，OO分析设计迅速发展，技术基础以及理论工具都可以使我们摆脱对数据库模型的依赖，从OO等抽象的高度来分析设计和实现系统。
这时，数据库无论在设计和运行时，都被降低到和表现层界面同样位置的一个状态，已经不是我们关注和分析的重点，如果说舞台上有唯一的一个聚光灯，那么这个聚光灯已经聚集到业务建模上来。
更有甚者，在OO基础上诞生了四色原型模式等新一代更抽象的分析方法，从此开始MDA开始新征程。
而我们很多国人，还停留在石器时代，在此争辩，你们到底怎么啦！赶快上路啊！
不过，我也相信现在的开发模式，正在朝这个方向上发展。
--错误的前提下,什么东西都可以推论出来.
没看你的<<数据库时代的终结>>.因为标题就不对,还有什么好看的.我猜您的真实意图是想由"思维"来主宰"记忆",而不是由"记忆"来限制"思维"吧.呵呵
这样说话的人，很容易走火入魔。楼主要注意了。
“数据库专家Oracle都来做中间件了”，用这来证明数据库时代要被终结了？地球人全知道，Oracle老板是一个怎么样的人？Oracle很有野心，它希望凭籍Oracle的成功，把中间件的主导权也拿到自己的手里。
写了很多。可看不出一点“数据库时代终结”的实质性东西。
恕我直言，楼主的基础概念还掌握得很不好，离研究这么高深问题的距离还很远，还是搞实际一点的东西吧。
这是很笑话的命题，当我们打开编辑器开始输入文本时，我们需要考虑这些文本是如何保存到硬盘上，在硬盘上格式是什么吗？
如果以这样低层次的技术都要搞清楚作为衡量程序员的基础，那么世界上所有程序员都要从汇编-->操作系统都要完全掌握，可能吗？你的脑筋怎么那么死？
这是一种典型的向下思维，我们程序员要站在前人的基础上，培养自己的向上模式思维，更关注业务领域设计，更快更好做好我们的业务系统，而不是一个操作系统。
数据库时代总结，谁来主宰？
MDD(模型驱动设计)/DDD实际就是革"数据库"命的！
现在在一个Struts+Spring/jdon+Hibernate系统中，是根本无需数据库设计，数据库在code completion后部署才会产生。
你可以查看开源软件的appFuse，在其中你都无法寻找到数据库SQL结构，甚至找不到Hibernate Mapping文件，它们都附属在Domain Model 对象中了。
如果这么极端的例子无法接受，学习学习JiveJdon3，它也是一个DDD设计的案例，只是数据库使用了以前版本的，实现一个过渡衔接。
下面是这段时间首页文章都是回答这个命题的。
面向ο蠓治`^程：
http://www.jdon.com/jive/article.jsp?forum=46&thread=27813
实战DDD(Domain-Driven Design领域驱动设计)：
http://www.jdon.com/mda/ddd.html
http://www.theserverside.com/news/thread.tss?thread_id=42602
事发原因是Arjen Poutsma在他的博客The Ancient Art of Programming的一文Domain Drivel中谈到和本文提到的OO系统相关的意见：
Arjen Poutsma说：
计算科学告诉我们有三种方式来表达数据：
1. Object graphs (i.e. Java or C#) 对象
2. Relational data (RBMS) 关系数据库
3. Hierarchal data (XML or HTML) 树形层次数据
Data is generally stored in relational databases, and converted to Java or .NET objects using some kind of ORM tool. Next, we use the objects to invoke business logic, and finally, we display them on an HTML page. I find this very amusing, it makes me feel we are doing something wrong here.
译文大意：（现在J2EE OO系统大部分是这样做的，如本文提到的：）数据通常保存在关系数据库中，然后通过一些ORM工具转换为Java或.NET对象，我们可以使用这些对象进行业务逻辑处理，最后将他们显示在HTML页面上，这给我的感觉好像有些问题。
Recently, though the influence of books like Domain Driven Design, it has become fashionable to think that a rich Domain Model is one of the most important things there is.
最近，因为Domain Driven Design书籍的流行，一个丰富的Domain Model概念被提出来了。
Well, that might be the case for you as an OO developer, but for the Enterprise the database is much more important.
不错，也许这样你就成为了一个OO开发者，但是企业数据库也许更重要！
It is not without reason that a large number of databases outlive the applications built around them.很显然很多数据库比他们的应用系统活得更长。
And for the user of your Web application the most important part is the HTML UI he or she is looking at.
对于Web应用系统，最重要的是人们看到的Html界面（这也是某些坚持AJAX比DDD更重要的原因）
Finally, in this SOA day and age, the OO business logic is probably not the only business logic that is there. Your application is part of a team of services, the business logic on the mainframe is just as important!
最后，在SOA年代，OO业务逻辑大概不只是就是某个地方一点点业务逻辑，你的应用是一系列services服务的一部分，大型主机中业务逻辑也重要。
Now, I’m not saying that a rich domain model is not important. I’m just saying that ― as with any solution ― it is not a silver bullet. Use it when it gives an advantage, but don’t swear by it. In the grand scheme of things, your precious OO model is not as important as you think it is.
当然我并不是说胖Domain Model（rich domain model ）不重要，我想表达的是：正如其他解决方案：它不是银弹，使用其优点。