本质上也属于动静结合：

动：SOA服务 事件 REST 语言方法/函数 SQL

静：数据表中数据 内存中数据(类实体) 其他资源数据。

一个基本架构需要由动静结合，比如如果你发明一种语言，或一种框架，或一种软件生产方式，至少需要一个动一个静的方式。

当然，更多是多个动静结合，给人有些复杂，比如：

动组合：REST+服务+语言方法函数+SQL；再加静：数据表中数据 。

这么复杂是有原因的：将现实世界中实体切分为动的方法和静的数据，这种切割有时是很残忍的，静的数据用数据表数据表达，动的方法就只能用SQL语句，因为操作数据表数据只能用SQL语句，而SQL语句不能直接运行，必须用Java等语法函数来执行它，这就又多了一个动词。

如果我们反过来想想，不把实体残忍用动静切割，也不用过去的数据库，直接把现实世界中的对象作为类实体搬到内存中，是不是会简单些？比如：

REST + 内存中类实体 + 事件

REST用来实现外部联系，内存中类实体实现内部动静功能，比如实体内方法实现动功能，通过事件主动驱动外部，REST是被动接受外部。

数据表数据消灭了，SQL动词也就没有了。一切变得简单。

当然现在通用简单办法是：就只用数据库，比如只用REST+关系数据库，或只用REST+NoSQL数据库，也很简单。

其实，现在很多的与数据库相关的系统，尽管用的是JAVA，到头来都不是在使用OO，而是以面向过程思维用JAVA来，调用数据库而已，都是挂羊头卖狗肉。把OO误导得一塌糊涂，纵观网上，比比皆是。

以对象为模型的系统，我认为是应该存在于内存的（若果扩展到硬盘的话，是一种虚拟内存的做法）。一旦把对象打散为数据，那么我们操作的永远是数据而不是对象，可以看看现在的教程都是修改数据库的数据，而不是修改对象，这教坏了多少想OO的程序员呢。在OO中使用数据库，对初学OO危险的，很容易被误导，必须要了解数据库不能决定任何领域模型，或者OO中最好不要存在数据库这一概念（不能理清其地位是非常危险的）。

用hibernate的OO用法是正向工程，看看网上还剩下多少正向工程的资料。“反向正用”也可，不过新手不懂这东西，于是又误导了——数据库表成为了模型。把保存到数据库看成一种“额外的”风险回避方式，对他们来说可能已经很难了。

非常同意banq，要么面向数据库（REST+数据库），要么面向对象（REST+DDD），混合的话，只会复杂而已。

非常赞同SpeedVan。我就是一个正向工程的坚持者。当我用.net时，我可以花半年的时间用微软DSL写一个类图设计工具可以正向生成ORM框架和数据库。现在我用hibernate，我仍然找了一个hiberObject，可以正向生成hibernate。这个在我的团队开发管理中非常重要的。