领域驱动设计 — 概念
领域驱动设计 — 方法论
领域驱动设计 — 实战
实战形容模型分析设计中需要遵循的过程及设计方法，供模型设计参考，以构建高质量的模型。文章形容的内容建立在业务领域规划指导下，建立应用模型的规范，包含对概念模型、逻辑模型、物理模型的分析和设计方法相关的内容。下面跟大家分享9年前在做企业应用软件时的模型设计方法
模型设计方法
1. 总论
1.1 规划方法总图
image.png
1.2 规划过程
image.png
需求调研阶段对应“规划方法总图”第二列
image.png
在规划的过程中，我们按照上图3箭头的方向进行，在矩阵的每个格子中同时做ER和DFD两方面的分析和设计
1.3 分析设计准则
整个模型设计的过程是一个从整体到局部、从高层模型设计到细节逐渐细化的过程。模型设计过程可以分为三个阶段：
1》概念分析阶段
2》逻辑设计阶段
3》物理设计阶段
每个阶段的输出都是下一个阶段的输入，每个阶段完成后，都要进行阶段性的评审。并根据评审结果修改输出物，若修改范围涉及上一阶段输出，就应该返回修改上层输出，保证上下层设计一致性。这就是一个自上而下设计、自下而上验证并且不断迭代完善的过程。同时，在每个阶段内部，在做一层、层推导的过程中，一样总从上面的准则与方法
image.png
1.4 3X3矩阵
3X3矩阵是方法论在模型设计各阶段关注点的整体形容，系统设计的整个过程都是围绕3X3矩阵依次进行的
image.png
横向分为概念、逻辑、物理阶段，这是软件工程角度的划分
image.png
纵向分为业务、管理、实现三个层面，这是业务角度上的划分，它们之间是一种并列关系，但是它们之间互相联络，只是它们各自关注的角度不同
》业务
解决核心业务事件(直接使用户受益的活动)，该类业务活动的某环节一旦中止，业务即不能正常展开
》管理
解决为了使业务运转的更好所添加的管理、监控类活动，主要分以下两类：一类是对活动本身的监控与管理，即规则管理；另一类是对活动结果的监控与管理，如运营分析
》实现
解决为了使核心业务流程能够正常运转所需要展开的辅助活动，明确业务限制条件。如：异常解决，支持与就绪，与参加人的交互等
1.2 模型推导方法概述
1.2.1 活动的推导方法
使用ER对活动（组成整个流程中的具体的解决点）进行建模，是对传统ER建模的扩充。这种方法适用于对业务活动、管理活动等动作的建模，针对于业务系统或者者系统中的活动。一个活动的产生至少需要两个参加者，这两个参加者之间由于活动而产生的关系必然是多对多关系
如何识别业务活动？
1）从需求分析中的事件活动来
2）从动词文法分析
表示动作行为的动词，如：打、拿、批评、学习
表示生命周期的动词，如：创立、使用、删除
image.png
如何推导？
首先2个实体之间多对多的关系进行平衡开展，步骤如下：
Lark20190331223640.png
接着，对已平衡开展的活动进行分解：上层的活动进行分解成下层的多个活动；即下一层的所有活动完整支撑上一层活动。下一层的活动可能发生于下图中的橙色关系中的一种或者多种。E1自关联活动、E2自关联活动、实例自关联活动，依然菱形开展。自关联活动可能是实体自身之间、或者者它的一个或者多个子实体之间的活动。如下图：
image.png
活动分解有两种情况：
并列子活动：子活动之间是并列执行的，某一子活动不依赖于某一子活动的执行结果
image.png
串行子活动：子活动的执行是有序的，某一子活动依赖于某一子活动的执行结果
image.png
1.2.2 静态关系
实体之间的静态关系一般体现为此时此地实体之间的从属、依赖、依存、分类等关系，传统的ER建模实践中最常见的就是从属关系，从属关系体现为一对多关系、分类关系
如何识别从属关系
1）从需求分析中的业务对象的组织结构、形式、状态等获取
2）从动词文法分析，表示关系和存在的动词（静态类动词），如：包含、构成、有、在、是等
image.png
3）分类
image.png
大部分的模型推导都是静态和活动两种推导方法
1.3 模型对到前准备
借鉴行业成功经验整理出来的信息需求是信息及模型设计的关键输入，也是衡量模型设计质量的标准。好的模型设计的首要因素是对业务的了解，包括对现有业务经营模式的了解以及业务发展趋势的分析，而不是模型设计的方法和技巧
和模型设计相关的需求收集与分析主要包括以下少量方面：
》模型设计目标以及覆盖业务范围的定义，以确定模型设计需要包含哪些信息和数据
》模型设计时间进度的要求，以确定计划投入的资源
》收集整理业务概念、术语、信息及数据的解决规则
》分析影响业务经营成功的关键因素，也就是核心的业务经营理念，以及支撑这些因素所需要的数据。例如以用户为中心是一个关键的业务经营模式，在数据层面如何有效的支撑。
》性能相关的信息，如业务的规模、吞吐量、相应时间的要求等，以确定性能设计方面需要考虑的问题以及处理方案(主要在物理模型设计阶段考虑相应的处理方案)
》对应用系统期望的有效运行期限，以及在有效期内业务变化的可能性的分析，这些信息会影响期望模型支持哪些层次上的变化
》对已有应用系统的模型的分析，也是新的模型设计的重要信息来源
1.4 概念模型分析阶段
概念模型是技术中立的，从业务的视角对企业经营过程中涉及的信息进行结构化形容，是高层次的粗粒度的模型，是对现实世界问题空间的IT表达（信息模型），不包含设计实现细节的设计模型
概念模型是对企业业务经营过程中涉及的信息的结构化形容；是技术中立的模型；是从业务的视角对信息的结构化形容，通过关键的实体、关系、规则的形容定义关键业务概念；概念模型是分析模型
》输入：规范、需求文档；其它相关模型文件等；业务目标、范围与定位
》输出：概念阶段ERD、概念阶段DFD、概念阶段事件列表、概念阶段交叉校验、业务场景验证文档、业务功能与角色对应关系
1.4.1 目的
概念分析用IT语言表达现实世界问题，通过对业务和管理方面的分析，分析出所有的业务概念实体，定义业务概念，阐述清楚实体之间的基本关系，确定业务概念的关键属性及其值域
1.4.2 分析步骤
》初步划分业务活动范围
》寻觅业务活动范围中的业务实体并形容定义
》分析并形容业务实体之间的关系：从属关系分析；业务解决活动分析；管理活动分析
》分析并形容业务实体关键属性
》分析属性所对应的业务值域
》业务场景校验、CRUD校验
概念模型的工作
》目标：对关键业务实体、实体关系、相关业务规则建模，形成高层次的实体关系图
》寻觅并形容与实体类、关系相关的业务规则
》从高层概念引出要分析的核心实体，以及之间的关系
》核心实体进行定义，以期大家对某个概念统一认识
》将活动按菱形开展，所有的一级的活动一律开展
》将从属关系进行形容
》将上级的活动分解成更细粒度的二级活动
》继续分解，直到分解到直接业务人员不可见为止
》分别将业务活动、管理活动、实现层面活动分解到位
注意事项
》只分析业务人员角度可见的ER关系
》不可以系统中如何设计的角度（系统实现角度）分析ER
》活动的开展使用菱形开展方法
》实体可以添加核心属性
1.4.3 分析实战
1. 承接
要么承接企业级概念模型，要么从最头上的业务活动推导到领域核心业务活动。比方业务活动，最初的起点在业务活动的参加人之间的经济活动，对其进行建模，并且按照菱形开展方式进行推导。以参加某活动为例：
image.png
而后，根据我们分析的业务领域，按照“生产关系”这个纬度将“参加人”实体进行分类，分为“消费者”和“生产者”，并且对“消费者”和“生产者”这两个业务概念进行定义（这里就不写出了）
image.png
而后，“参加人”自身的“经济活动”关系就具体化为“消费者”和“生产者”之间的“等价交换”关系（活动）
image.png
之后，“等价交换”活动可按照菱形方式进行平衡开展
2. 获取业务概念
1）框定业务范围
在本文档里业务范围我们也称为业务领域。是我们要研究的跟某个核心事物相关的具体的业务集合。
假如有业务文档，我们可以从业务文档中搜寻业务实体和业务事件。
2）寻觅关键业务概念，转变为关键业务实体，形成实体的定义；
比方第一节中，寻觅的关键业务词汇：参加人、生产者、消费者、经济活动（展开经济活动）、等价交换；其中“参加人”、“生产者”、“消费者”均为名词、业务活动的参加者、承载者，可以形成实体。
3）根据业务事件寻觅并定义关键业务实体之间存在的关联关系；
关键业务词汇中的“经济活动（展开经济活动）”、“等价交换”是业务活动、表示动作的动词，抽取出来作为业务承载者之间的活动类关系。
根据参加人可以分为生产者和消费者，我们可以获取这3个业务概念（实体）之间的静态类关系，这样就取得了3者之间的分类关系。
4）分解过程中，核心属性假如需要进行深入分析，或者者其在业务要求使得它不具有原子性，需要将其拉出来作为一个实体，进行研究。
比方下图中，当我们研究的业务领域为“研究汽车的运输能力”的时候，我们不需要关注汽车的组成，有几个轮子，发动机是什么型号的；但是当我们研究“汽车配件”或者者“汽车装配”的时候，我们就需要关注汽车的轮子、发动机、车体等属性，甚至我们需要知道轮子、发动机、车体等它们自身的规格信息，我们就需要将其抽出来作为一个个的新实体
image.png
3. 获取业务活动
列出业务层面的事件列表，将业务解决活动逐层地进行分解。
一个业务领域为了实现一个目标，需要有多个业务活动进行支撑，而每个业务活动又需要多个子活动对其进行支撑。自上而下是活动的分解过程，自下而上是目标的支撑。
image.png
从需求文档或者者参考资料整理出业务事件，形成事件列表，按照层级进行展示；例如下表余额管理的事件列表：
image.png
业务活动的分析可以是一步到位的，也可以是逐渐完善的（可能需要屡次迭代）
4. 模型推导
根据实体之间的从属关系画出静态关系，将每个活动按照菱形开展的方式画出ERD。业务活动是分层的，所以对应的这些活动的ER开展图也是分层的。推导的过程中，每个实体都有来源，要么是通过从属关系分析出来的，要么是通过业务活动菱形开展推导出来的，是不能凭空出现的。
ER的推导是一个屡次反复迭代的过程
image.png
image.png
image.png
image.png
image.png
在活动推导过程中，核心实体的核心属性会最早分析出来，并且有可能会在分析的过程中分离成一个单独的实体。在活动的推导的后期，给实体补充上业务关键属性、以及属性的值域。
5. 总图
将所有推导的最下层的ER图，按照业务、管理、实现3个层面分别合并到一张图上，静态关系合并到一张图上，形成概念阶段的ER总图
image.png
6. 分析业务功能与角色对应关系
从分析中提取出参加人，一般这些参加人属于角色的范畴，单独指个体的比较少。将参加人和他参加的活动结构化展现出来，即可以构成“业务功能与角色的对应关系”
image.png
1.4.4 概念模型做到什么程度？
业务事件分解到业务操作员可见的事件为止，ER推导同步。假如有需求文档，若所有的需求ER图都表现了，就算做到位了；假如没有需求，从0层总图往下推导3层
1.5 逻辑模型分析阶段
逻辑模型设计是在概念模型设计的基础上扩展和细化形成的处理方案视角的模型。逻辑模型重在设计，而概念模型重在分析。逻辑模型从概念模型转换形成，有建模工具支持这种模型之间的自动转换。
》输入：概念阶段的输出物；需求类文档
》输出：逻辑阶段ERD、逻辑阶段DFD、逻辑阶段交叉校验、概念阶段与逻辑阶段实体对应关系、概念阶段与逻辑阶段功能对应关系、业务场景验证文档、功能清单
1.5.1 目的
逻辑模型设计的目标就是设计支持现实世界概念模型的逻辑模式和子模式（外模式），将概念模型转换为某类数据库（关系或者对象数据库）所支持的数据模型。在该过程中需要对概念设计阶段中牵涉的业务，逐渐细化，以达到能在系统中实现。为此，需要从业务功能中笼统出解决功能，并且对实体和解决进行归纳笼统。并且在分析数据流时，要表达出具体数据的流向。
逻辑模型是在概念模型设计的基础上，加入设计的因素，对模型元素进行细化和扩充，并逐渐应用规范化的策略对数据规范化，消除数据冗余，形成理想结构的详细的模型。逻辑模型是从处理方案的角度对数据的结构化形容；逻辑模型依然是技术中立的模型，用于指导系统建设的模型设计。但逻辑模型并不是系统的数据结构，系统建设时，依然需要在逻辑模型的指导下做进一步的设计，并进行物理模型的设计，形成最终的系统数据结构。
1.5.2 设计步骤
》在概念分析的基础上划定系统边界
》去除仅仅代表业务概念，而不需要应用系统实现的实体和解决
》将模型转化为关系模式
》将模型中相近的实体和解决进行归纳笼统，消除冗余
》引入设计层面所需要的实体和解决，并逐层细化
》设计实体类的属性，设计相关的值域，确定实体类的候选标识并进一步确定主标识，建立与属性相关的业务规则
》定义逻辑实体和解决
》业务场景校验、CRUD校验
逻辑设计的工作
》在概念模型分析的基础上，设计出展示系统中如何进行实现这一视角的ER模型。
》确定系统范围与边界
》去除仅仅代表业务概念，而不需要应用系统实现的实体类
》将概念模型中相近的实体进行归纳、分解
》按照规范化理论，对数据模型逐渐规范化，去除冗余，使模型结构更为清晰、规范
》引入设计层面所需要的实体类，包括为分解多对多关联关系引入的实体类，处理继承关系引入的实体类，添加新的设计实体类
》设计实体类的属性，设计相关的属性域，确定实体类的候选键并进一步确定主键，建立与属性相关的业务规则
注意
》逻辑模型依然是一个技术中立的模型，逻辑模型的设计不要过多考虑关于性能方面的问题，也不要考虑数据如何分布、存储
》最终设计出全属性模型
》通过和DFD进行交叉验证找问题
1.5.3 逻辑设计实践
1. 确定范围
概念模型分析的比较全，在逻辑阶段要进行细化、笼统和取舍，这里说一下取舍。取舍是基于概念模型，在概念阶段考虑实现层面的时候进行的动作。主要是因为项目的起因、业务领域与其它领域交互的起因、技术难度等起因，人为地将逻辑设计的范围进行框定，并且将边界的设计添加上。
逻辑模型的范围会发生变化，一般范围会变小
image.png
2. 从概念模型转到逻辑模型
1）ER从属关系的转换
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联络转化为关系模式,这种转换一般遵循如下准则：
a. 概念层面的实体可直接转成逻辑实体。根据实体类、关联关系存在的类似性，进行适当层次的笼统，形成更为通用的概念；
b. 一个m:n联络转换为一个关系模式。与该联络相连的各实体的码以及联络本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
c. 一个1:n联络可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。假如转换为一个独立的关系模式，则与该联络相连的各实体的码以及联络本身的属性均转换为关系的属性，而关系的码为n端实体的码。
d. 一个1:1联络可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
e. 三个或者三个以上实体间的一个多元联络转换为一个关系模式。与该多元联络相连的各实体的码以及联络本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
f. 同一实体集的实体间的联络，即自联络，也可按上述1:1、1:n和m:n三种情况分别解决。
g. 概念层面的实体属性可直接带到逻辑实体中，补充类型和长度等形容
image.png
2）归纳与细化
a. 对于实体进行完善、细化和笼统。
b. 将模型中相近的实体进行归纳笼统，消除冗余，从信息实体中提取出数据实体；笼统是一个由多到少的过程，目的是要达到模型与业务的无关性，实现数据模型的稳固持续发展
c. 笼统过程中属性和值域需做相应整合
d. 引入设计层面所需要的实体，而后对系统展开的活动进一步细化，使得解决功能越来越逼近于函数的实现形式；细化是一个由少到多的过程，细化的目标是完善实体和功能
e. 细化过程中需补充完整属性和值域
image.png
image.png
3)业务活动向系统功能的转化：事件的笼统、合并与细化
image.png
image.png
image.png
image.png
4）功能清单
a. 从业务事件取得系统功能
b. 功能继续进行分解、归纳迭代
image.png
5）业务实体归纳
image.png
6）属性与值域
a. 增加全属性、数据类型
b. 值域转换
7）结果图：将过程ER合并到结果图上
1.5.4 逻辑模型做到什么程度
直接转换成物理模型即可以在数据库里面生成正确的表结构
1.5.5 概念模型和逻辑的区别
从“业务范围”角度
概念模型》＝逻辑模型（实体表示的业务范围上，不是实体数量）。
从“图”这个角度
概念模型的实体和逻辑模型的实体是多对多的关系。在确定的范围（逻辑实现范围）之内，概念模型的实体在逻辑模型中都能找到。
逻辑模型中不存在多对多关系。
概念模型的实体不要求画出所有的属性，逻辑模型要求是全属性的；数据类型的要求同上
1.6 物理模型分析阶段
物理模型是在逻辑模型设计的基础上，结合具体使用的数据库管理系统，加入对系统实现的考虑，包括系统的可实现性、系统的性能等。从实现的角度，在逻辑模型的基础上做必要的反向规范化的设计、模型物理结构的设计（包括索引设计、存储参数设计、视图设计、数据分割等），加入程序控制和动作控制
1.6.1 目的
物理模型设计的目标是根据DBMS特点和解决的需要，进行物理存储等安排；根据系统和客户数量对逻辑设计中模型的功能与实体进一步细化，使功能/数据能在具体的系统中实现，需要考虑效率、接口等问题。在该阶段还需做少量数据结构的冗余设计以提高数据访问的性能，包括添加冗余字段、添加派生字段、添加冗余表、对表结构重组、数据分割（水平分割、垂直分割），优化设计索引、调整数据库对象存储参数、设计视图等。
在做数据结构冗余设计的时候，要同时考虑数据完整性的保证机制。
》输入：逻辑阶段的输出物；需求类文档。
》输出：物理阶段ERD、物理阶段DFD、物理阶段与逻辑阶段实体对应关系、物理阶段与逻辑阶段功能对应关系、功能清单
1.6.2 设计步骤
》设计UI/系统接口
》考虑性能，进行反规范化设计
》设计数据存储(内存/文件/DB)
》设计索引、视图、分区、存储参数等性能参数
》引入具体实现层面所需要的实体和解决，并细化
》设计程序异常解决及系统管理
》设计其余技术实现细节
》场景校验、CRUD校验
1.6.3 物理设计实践
1. 逻辑模型转换为物理模型
1）转换到关系数据库
选定数据库，使用CASE工具（PowerDesigner）直接进行转换。
逻辑实体转换为数据库的物理表，关系转换为表间的外键束缚，数据类型转换为具体DBMS的数据类型，逻辑值域转换为物理模型的值域。
2）转换到其它结构
内存数据库、内存、文件
2. 性能设计
1）性能需求
数据量：初始数据量有多少，每天或者者每月的数据增量是多少？每天或者者每月每个功能的数据增量是多少？
响应时间：关键业务的响应时间是多少
并发：高并发的业务（功能）是哪些？多少的并发量？
热点（数据的存取频度）： 最多的数据读写发生在哪些表上？
2）性能设计的手段
分表
》水平分割：
根据一列或者多列数据的值把数据行放到两个独立的表中。
应用场景
A 表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询速度。
B 表中的数据原本就有独立性，例如表中分别记录各个地区的数据或者不同时期的数据，特别是有些数据常用，而另外少量数据不常用。
C需要把数据存放到多个介质上。
》垂直分割：
把主码和少量列放到一个表，而后把主码和另外的列放到另一个表中。
应用场景
A 表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询速度。
B 表中的数据原本就有独立性，例如表中分别记录各个地区的数据或者不同时期的数据，特别是有些数据常用，而另外少量数据不常用。
C 需要把数据存放到多个介质上。
分表后，需要有相关的路由策略（比方路由表）保证对分出来的表的精确访问。
合表
在表结构相似的基础上，数据量不大，读写不频繁，可对表进行合并，合并的表可添加一个字段用以标识不同的业务数据。
冗余
最显著的打破范式的设计方法就是冗余法，以空间换取时间的做法，把数据冗余在多个表中，当查询时可以减少或者者是避免表之间的关联。
冗余设计必需要有相应的措施保证数据一致性
索引
创立索引能显著提高数据的查询速度，但同时也添加了插入、升级和删除等维护任务的速度。正当的索引设计要建立在对各种查询的分析和预测上。定期做索引的碎片整理，定期进行表分析，以避免索引失效
1.6.4 物理模型设计到什么程度
就ER图上来说，表、字段、数据类型、主键、外键、唯一索引、索引、视图、触发器等定义完备，可直接生成建库脚本
1.6.5 逻辑模型与物理模型的区别
从“业务范围”角度
逻辑模型＝物理模型（实体表示的业务范围上）。
从“图”这个角度
逻辑模型的实体和物理模型的表是一对一、一对多的关系占绝大多数。
物理模型中表的字段》＝逻辑模型中实体的属性。
2. 模型验证
在模型分析设计阶段，都需要对模型设计的结果进行阶段性的验证，以及时发现模型设计中的问题，对模型及时更正
2.1 验证什么
模型验证，主要验证模型能否完整的支撑业务、支撑上一层的推导、设计能否正当、本层设计能否和上层有冲突、设计能否和业务有冲突。
模型验证需要考虑以下几个方面（以第一条和第二条为主）：
》验证模型的完整性：模型能否覆盖需要的数据，能否能够满足业务需求，支持关键的业务经营模式和理念
》验证模型的可行性：模型能否简洁易懂，使业务人员能够精确把握和了解模型，基于模型的应用系统能否能够实现和实施
》验证模型的可复用性：模型的设计能否具备良好的通用性，能够被多个应用系统复用。模型的设计不能针对特定的应用系统组织和设计，否则很难具备良好的通用性
》验证模型的稳固性和灵活性：稳固性和灵活性是验证模型适应业务变化的能力。面对业务变化，模型不需要改变就能够适应业务需求，是模型稳固性的体现；当业务变化对模型产生冲击，通过对模型进行适当的扩展，而不影响已有的结构来适应业务需求，是模型灵活性的体现
2.2 验证手段
业务场景验证是验证模型和业务能否符合的手段，CRUD矩阵是验证设计能否正当的手段，ER和DFD的交叉验证用以验证推导过程能否一致
2.2.1 业务场景验证
首先，形容业务场景，即先拿出某个业务场景，获取参加人、流程、输入输出等相关信息，而后针对该业务场景的实现，一个步骤一个步骤地指出每个步骤分别是谁操作、读取什么输入、怎样加工、解决的规则是什么样的、解决结果保存到什么地方？即可使用数据模型说明清楚如何完美地表达这些业务场景。
假如，流程串不起来，或者者该输入的数据找不到，或者者输出数据没有地方保存，这些都是显著的错误，出现其中之一即为不通过。
2.2.2 CRUD验证
CRUD分别代表对数据的创立、读取、编辑升级和删除。CRUD验证的做法是：
将业务事件（活动、功能）和实体（属性、值域）分别放置到一个矩阵的行和列上，这样，每个业务事件就和每个实体都有一个交叉的格子，在每个格子里写上代表的业务事件对此实体操作的字母，如C（创立）R（读取）等，就构成了一个CRUD矩阵。
在我们研究的业务领域中，每一实体（属性）必被某一业务事件创立，每一实体（属性）被且仅被某一个业务事件创立，每一实体（属性）必被某一业务事件读取，每个实体只能被一个业务事件升级，每个实体只能被一个业务事件删除。
image.png
若出现上图右上角，两个实体（E2、E3）都被几个业务事件（P2、P3、P4）进行同样的操作（这里是C操作，比方同时还有同样的R操作等），那么这两个实体（E2、E3）可以考虑进行合并（当然还需要考虑这两个实体的属性能否具备类似性）。
两个业务事件（P2、P3）都对几个实体（E2、E3）进行同样的操作（这里是C操作，比方同时还有同样的R操作等），那么这两个业务事件（P2、P3）可以考虑进行合并（当然还需要考虑这两个业务事件还有没有其它的类似性）。
以上案例说明CRUD主要用于验证设计的正当性
2.2.1 ER和DFD交叉验证
对于一个活动，可以分别使用ERD和DFD的形式形容，DFD形容活动本身的过程，ER可以形容活动的过程，同时也能形容活动最后产生的结果、实体之间的静态关系。那么，用ER和DFD分别形容的某个活动，就其形容的过程和结果来说应该是一样的。
ER和DFD的相互验证的关系见下图：
image.png
假如ER和DFD对于活动的表达不一致，那么说明二者的推导过程中至少有一个是错误或者者不合适的
