一个机械工程师也谈谈对数据和领域建模的理解

前言：最近jBeanBox项目收尾，感觉用Java初始化块来代替Spring的XML配置这种模式挺好的，手中有了这把锤子，于是看什么都象钉子，这不，又看上了Hibernate，  SSH三兄弟，紧跟在Spring后面，也是用XML或Annotation配置，配置也是固定的，不能在运行期动态生成和修改，好了，钉子就是它了。新项目名字都想好了，就叫jSQLBox，用来代替Hibernate。对了，顺便看看Hibernate还有什么其它毛病没有? 可是找来找去，没发现什么缺点，除了太复杂之外，想不出有什么问题。如果只是为了给Hibernate增加一个配置方式而重新发明一遍轮子，岂不是很可笑了，不行，一定要找出点毛病来，没病也得挑出病来。于是左看右看，也不知是我眼花了还是看的时间太长了，现在越看越觉得Hibernate象是一个过度设计的例子。于是本吐槽文诞生了，Hibernate的铁杆拥趸们可以不用看了，因为本文的目的就是贬低Hibernate，借以抬高这个八字还没一撇的jSQLBox。

开始前，先澄清一下"领域逻辑"和"领域模型"这两个词的区别，"领域逻辑"表示企业的内在业务规律，与是否使用了软件无关，这一点应该没什么疑问。 "领域模型"从中文字面理解应该是一个企业的业务模型，与软件术语无关，但是这个词在Martin的《企业架构》书中被转换成另一个含义，就是建立在面象对象基础上的概念模型，模型本身包含数据和行为，这与软件工程中的对象模型概念恰好一一对应，于是"领域模型"往往和"对象模型"等价，并且由面象对象软件来实现。 "领域模型"不是本文讨论的重点。但是笔者的观点是企业应用恰恰是 "领域模型"不能发挥作用的场合，这属于个人观点，如有不同意见请先别拍砖，听听我的理由：1）当一个问题复杂到用表格不能处理，必须借助面象对象模型来实现的地步时，通常已经非常复杂或冗长，已超出了人能理解和操纵的范围，适合计算机处理；而企业逻辑通常和人、钱、物打交道，逻辑简单，是能被企业中的业务专家理解和解释的，用复杂的模型来解决本质上很简单的问题是把问题复杂化。企业业务专家的头脑中基本没有对象、继承这些概念，他们的头脑中通常是一张张数据表，典型的代表就是企业会计，和他们谈面象对象是对牛弹琴。来到哪个国家，就要说哪个国家的语言，这才好交流。2）解决复杂问题的面象对象模型通常不是并发访问的，因为业务本身的复杂性使得并发访问编程难度极大，也就是说当你想解决的问题越来复杂时，业务本身的并发限制就越来越高，就越来越不能被称作企业应用3）面象对象模型通常用树或图结构来表示，往往必须用专用格式来保存，很难用统一的格式来存储，例如Office文档、三维制图、电路排版软件、网页文档等，它们各自有自已的专有文件格式，虽然有XML之类的通用格式，但显然XML是一种树结构而不是可以放进数据库的表结构。个别情况下，对象模型本身就是持久层，如电路板布线图，打印出来就可以用于生产排版。当一个面象对象模型可以用O-R工具来映射成数据库表保存时，只能说明这个模型太简单了，简单到可以直接用少数表格来表达了。4）面象对象模型是随着计算机技术进展才出现的，最常见的应用场合是在计算机帮助下可以建立以往人力不能建立的复杂模型，建模经常是工作的全部或重点；而企业应用建模本身不是重点，因为企业逻辑在面象对象概念提出之前已经存在，软件只是对企业逻辑进行表达和梳理，帮助企业逻辑更好地运作而产生效益。综上而言，用面象对象这个工具来处理企业应用，很可能是杀鸡用牛刀了，牛刀能不能杀鸡? 当然能，但是要练好牛刀很难，让一个开发团队都练好，更难。
在"领域模型"和"领域建模"出现之前，企业应用软件开始编制前，也是要建模的，这通常表示为互相关联的表格，并辅之以文字或图形、线条等来表达这些表格之间的关系，这就是传统的E-R模型(即通常说的”数据建模”)。本文以图1来说明一种基于数据(表)建立企业逻辑模型的优点，(如因转载原因不可见，请打开此图所在网页: https://github.com/drinkjava2/jSQLBox图片文件名为p1.png，因为下文都是基于此图展开讨论&#x