先看一个例子：
Case1：
客户资料的一条记录，是我们通常理解的“数据”，描述客户资料的数据结构定义的数据就是“元数据”（描述数据的数据）。
Case2：
系统参数的一条记录，是我们配置出来的“数据”，描述系统参数的数据结构定义的数据也是“元数据”。
Case1和Case2的差别：
Case1的数据的产生或变化不会在运行期直接改变软件的预置业务功能，只会影响后续业务功能的处理结果。
Case2的数据的产生或变化会在运行期改变软件的行为，直接提供不同的业务功能。
把Case2中的这种通过建模定义元数据的方式，期望提供一种配置化的设计方案从而改变软件提供的业务功能的设计方法称为基于元数据驱动架构。
这种直接基于case2大的类别的元数据，针对性的进行配置从而提供软件不同的业务功能的方式称为元数据驱动开发。
元数据驱动开发的基本思想，就是基于元数据对象声明式开发整个应用，围绕元数据对象创建界面、业务流程、领域服务、领域对象及物理存储表结构，围绕元数据对象进行测试（包括测试数据生成、用例管理等），围绕元数据对象进行局点个性化需求定制（包括界面、流程、服务、表结构等），围绕元数据对象进行问题定位，从而达到通过元数据对象驱动整个应用开发过程的进行。
如果基于元数据还把业务需求的需求分析+调测+安装部署+资料都搞定了，那么就是元数据驱动交付。
注意：CASE1和CASE2是相对一个特定系统边界来说的，反例是：对于系统A来说，CASE2中的这个数据就是CASE1的类别，比如：SM就是要管理这个系统参数实体，对系统参数实体的CRUD是SM的“业务”功能，再比如PM会管理商品/产品数据，这个数据对于PM来说是CASE1类型，对于OM来说就是CASE2类型的，因为不同的商品/产品,相同商品/产品的不同属性对于OM来说是要提供不同的业务功能的。
