业务模型和数据模型

在软件行业中，系统设计的核心是采用面向对象的方法进行分析建模。

但如今从事这行业的人，不少是没有受过系统化的软件工程方法训练的，他们在自学或报班学会数据库基础知识和CRUD方法后就算入行了。

一个典型现象：很多人在拿到业务需求后，第一件事是琢磨表结构如何设计，系统设计文档里首先体现的是ER模型。

这种方法是完全错误的，其问题在于：对业务模型和数据模型没有清晰的认识和理解。

业务模型

业务建模的过程，是将客观世界中的实体关系抽象为软件世界中的概念模型，因此业务模型的本质是要能与现实世界对应。一个好的业务模型是能真实的反映业务的真实面貌，它通过使用与业务同学达成一致的术语（在DDD里称之为统一语言），精确刻画业务上有哪些实体、实体间有哪些关系（包括关系的依赖方向和一对多等等）。因此你就能明白业务模型的作用主要是建立了业务与技术同学之间对话的桥梁，但业务模型不会涉及到任何技术实现的细节，它仅仅只是为下一步的系统实现提供”业务语义翻译“。

业务模型一般用类图表示。在类图中需要定义有哪些核心的业务对象，以及这些对象之间的关系是什么（依赖、关联、实现、继承、聚合、组合）。

数据模型

数据模型是存储设计，或称之为表结构设计，一般用ER图表示。在做数据模型设计时，一方面是严格基于业务模型，另一方面要重点考虑技术的可扩展性、性能等非功能性因素。

数据模型来自于业务模型，但与业务模型不一定一致。下面是几个例子：

对于同样的业务模型，在强事务场景下会用关系型数据库，在海量数据场景下可能采用kv存储；

在对检索有强需求场景下，可能采用大宽表设计，但在扩展性需求更高的场景下，可能采用纵表设计，甚至可能采用双写的方式；

在业务模型存在一对多关系的场景下，可能采用一个业务模型对应一张物理表，也可能采用多个业务模型对应一张表，典型的场景是将多个领域模型的操作日志、附件信息共用一张物理表，或是将一些模型的扩展信息以json形式维护在主业务模型的表里。