3.1　数据架构的设计过程

以往的数据架构设计是以数据库设计为核心的设计过程，如图3-1所示。前面谈到，当需求确定下来以后，团队首先开始的是数据库的设计，因为数据库是各个模块唯一的接口。当整个团队将数据库设计确定下来以后，就可以按照模块各自独立地进行开发了。在这个过程中，为了提高团队开发速度，应尽量让各个模块不要交互，从而达到独立开发的效果。但是，随着系统规模越来越大，业务逻辑越来越复杂，系统就越来越难以保证各个模块彼此独立、不交互了。

图3-1　传统的软件设计过程

当软件系统变得越来越复杂时，原有的设计过程就不能满足设计的需要了。在原有的设计过程中，首先进行数据库设计，而数据库设计只能描述数据结构，不能描述系统对这些数据结构的处理。因此，在第一遍对整个系统的梳理过程中，只能梳理系统的所有数据结构，形成数据库设计。接着，我们再次梳理整个系统，分析系统对这些数据结构的处理，形成程序设计。那么，我们为什么不能一次性地把整个系统的设计梳理到位呢？

因此，我们按照面向对象的设计过程来分析设计系统，如图3-2所示。当开始分析设计时，首先进行用例模型的设计，分析整个系统要实现哪些功能。接着进行领域模型的设计，分析系统的业务实体。在领域模型设计中，采用类图的形式，每个类可以通过属性来表述数据结构，又可以通过方法来描述对数据结构的处理。因此，在领域模型设计中，我们就把表述数据结构与对数据结构的处理这两项工作一次性完成了。

图3-2　面向对象的软件设计过程

这个设计过程的核心就是领域模型，然后以它为核心指导系统的数据库设计与程序设计。这时候，数据库设计就弱化为了领域对象持久化设计的一种实现方式。

领域对象的持久化，就是指在整个系统运行的过程中所有的数据都是以领域对象的形式存在的。譬如，要插入数据就是创建领域对象，要更新数据就是根据key值去修改领域对象，删除数据则是摧毁这个领域对象。假如我们拥有一台超级强大的服务器，那么我们不需要任何数据库，直接操作这些领域对象就可以了。但现实世界中没有那么强大的服务器，因此在设计实现的过程中，必须将暂时不用的领域对象持久化存储到磁盘中，需要时再从磁盘中恢复这个领域对象。这就是领域对象持久化存储的设计思想，而数据库就是这种持久化存储的一种实现方式。

所以，现在我们讨论的数据库设计，实际上就是将领域对象的设计按照某种对应关系转换成数据库的设计。随着整个产业的大数据转型，今后的数据库设计思想也将发生巨大的转变，数据库可能不再是关系型数据库了，可能是NoSQL数据库或者大数据平台。数据库的设计也不一定遵循第三范式（Third Normal Form，3NF）了，可能会增加更多的冗余，甚至是“宽表”。数据库设计在发生巨大的变化，但唯一不变的是领域对象。这样，当系统在大数据转型时，可以保证业务代码不变，变化的是数据访问层（Data Access Object,DAO）。这将使得日后大数据转型的成本更低，让我们更快地跟上技术发展的脚步。

因此，在数据架构设计这个环节，我们首先进行领域模型的设计，然后将领域模型的设计转换成数据库设计以及程序设计。这里大家可能发现了一个有趣的问题，逻辑架构设计包含了领域模型，而数据架构设计也包含领域模型。这其实反映了领域模型设计到底是谁的职责：属于逻辑架构的部分应当属于需求分析人员的职责，属于数据架构的部分应当属于设计人员的职责。但我认为，领域模型是两个角色相互协作的产物。未来敏捷开发的组织形成，团队将更加扁平化。过去是需求分析人员做需求分析，然后交给设计人员设计开发。这种方式就使得软件设计质量低下、机构臃肿。未来“大前端”的思想将支持更多设计开发人员直接参与需求分析，实现从需求分析到设计开发的一体化组织形式。这样，领域模型就成了设计开发人员快速理解需求的利器。