数据模型与领域模型

数据模型的使用远早于领域模型,实体关系模型出现后,数据模型就有了明确的描述方式,成为信息建模的主要手段。

很长一段时间,数据模型是描述业务的最可靠的手段,其中的原因很多,首先,数据模型可以转换为数据库的结构,落地为具体应用系统的一部分。数据模型建立在数据库的基础上,这使数据模型可以验证,是执行系统的一部分,而不是虚幻的文档。然后,在面向对象广泛应用之前,针对领域的建模比较薄弱,也缺乏将分析模型中的对象转换为设计的手段,因此,与代码相比,数据模型更为稳定可靠。

数据模型也存在一些不足,首先,数据模型无法表示动作,对于动作的表示经常转换为状态,比如,“废弃”动作,在数据模型中需要使用一个字段进行描述,“isAbandoned”,在软件中通过修改这个值完成动作。如果根据软件设计数据模型,可以在abandon动作中修改isAbandoned属性,可是,如果从数据模型设计软件,可能就无法区分需要在软件中定义一个动作,还是只是使用与其他属性一致的get/set方法。第二,数据模型中很难表述数据输入的顺序,因为其描述的只是静态关系。举个例子,一个计划有若干的草稿,计划和草稿之间是一对多的关系,那么,在草稿中需要保存计划的关键字。然而,在实际情况中,草稿是先于计划产生的,在草稿编写保存时,计划还没有被创建,也就不可能存在这个关键字。如果在设计数据模型时只关注静态结构,设计出来的软件就会很别扭。第三,数据模型中只有关系和实体两种概念,很多其他的概念都需要使用这两种关系表示,如果以数据模型进行设计,就无法区分真正的实体和使用实体变通描述的其他概念。比如,值对象的概念在数据库设计时是没有的,我们只能使用实体或者字段进行描述,而以数据模型作为代码设计的基础时,就无法区分这些概念。

领域模型基于代码进行设计,可以引入更加丰富的概念。但领域模型也有一些缺点,首先,领域模型是应用软件的一部分,混杂在各种代码中间,如果代码结构不理想,或者干脆没有源代码,那么就很难理解系统,数据模型没有这个问题,数据库结构可以忠实反应数据模型。第二,如果软件设计不是很合理,或者运行时间比较长,补丁比较多的软件,领域模型可能已经碎片化,散落在软件的各个部分,获取完整的模型几乎不可能,同样,数据模型不存在这个问题。

在数据模型和领域模型之间是分析模型。分析模型比领域模型更抽象,不依赖于具体的编程语言,使用UML等通用建模语言进行描述,分析模型类似于数据模型的概念模型,但比概念模型要复杂,并且也不如概念模型一样,可以直接转换为物理模型。分析模型往往是开发过程中的过程模型,因为很难对分析模型进行全生命周期的维护,使其和领域模型一致。