领域模型和数据库表结构对应关系

      以前我自己做过的项目中和别人的项目中都有这样的一些定论，就是往往先设计数据库表模型，然后根据表产生业务逻辑模型。譬如，在数据库中有一个表T_USER，在程序中就会有User类，所以一般情况就一对一的映射关系了。

      领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

 

      数据库表结构一般都由领域模型来，除了能够保存领域模型外，还需要考虑数据库本身的特征。

 

      我们个举例：相信很多都办过信用卡，信用卡表上有申请人的基本信息，申请人工作信息，联系人信息，从领域模型角度来说有三个概念类：人的基本信类，工作信息类和联系人信息类，他们是组合关系。按照这样数据库表设计如下：

 

  这样设计看上去也没有问题，有很多人说这样很清楚，这基本上也是一对一的映射。但是从数据库角度来说这样是最优化的吗?我个人这样可以这样设计,将三个表合在一起(这样不会破坏领域模型的,Hinernate的component可以实现),如下图:

当然也有它的缺点: 1.表操作比较频繁.2.表的扩展比较笨重

这样要平衡一下了,从领域模型角度来说,其实他们是一个业务实体,组合关系,不可分割.所以说对实体操作,第一种方案也会对三个表操作,特别是查询,第一种方案有两个外键,显然没有第二种快了.

 

      所以大家在考虑领域模型或业务对象时,要按照他们本身的原则设计,不要依赖于数据库表的结构.反过来做数据库表设计的时候不竟要完成领域模型的数据要求,还要考虑数据库的性能问题.