目前模型驱动架构的现状：
目前大部分的模型驱动架构，建立在领域驱动建模的基础之上，优点就不说了，我们只说缺点，那就是当我们的领域模型改变的时候，其他相关的模型层，都需要跟着改变，比如说持久层，业务流层，Bean层等等。当你的业务足够复杂，运维的时间足够长，维护文档的标准不统一等等，我们最后的项目还是一堆意大利面条。
我们有没有进一步去思考，基于上面无法解耦业务与持久层和其他层的原因是什么呢？---抽象，我们没有做到足够的抽象。所以我们没有办法做到代码的最大复用，需要写大量相似的代码，比如数据持久化，业务流调用编排等等。我们的业务方法是基于具体业务Bean的，不能通用。
好了，问题点出来了，我们能够解决这个问题吗？我想大多数的人，无法解决，那么我接下来文章要写的内容，就是提供解决上面这些问题的办法。
我们来看一下元数据的概念：
元数据就是描述数据的数据。大家估计早已背的滚瓜烂熟了，但是我们如何去定义元数据标准呢？我们还按照上面的套路，看看我们遇到的问题是什么，我们要做通用的可复用的方法。我们先从持久层下手。最终的目标就是屏蔽掉持久层的复杂度，只写一个方法，就能完成所有数据的增删改查。听起来很NB的样子。有些人是不是看到这里估计要破口大骂了。别急，我们往下看。
我们看看持久化需要哪些信息？下面是一条简单的插入语句（我们先不考虑数据库差异，我们后面讨论数据库差异的解决方案）：
INSERT INTO table_name ( field1, field2,...fieldN )
VALUES
( value1, value2,...valueN );
只要稍微有一点开发知识的朋友都知道上面的语句。我们拆分一下信息
固定部分： INSERT 、INTO、VALUES
变化的部分：table_name、field1、value1等等
我们需要用元模型来描述我们的SQL的信息。
元模型1： Role (角色-Table的概念或者类的概念)
{
id:模型中唯一识别Id
name:名字
metaType: Role
parentId:
context: { TableType：主/从 }
}元模型2：Property（属性-field或者字段的概念）
{
id:关键字
name:名称
metaType:Property// 元模型类型
parentId:父节点ID
context: { dataType: 字段类型, dataLength: 字段长度,pk: 主键 }
}我们看一下能不能用上面的信息来描述我们的数据表呢？
我们仍然那我们简介一节的内容来作为例子：
M1(模型)：这一层利用M2构建的元模型元素，来描述我们的具体业务模型。例如员工（Employee），并具有如下字段
Name=名字 kind=NameStringLength=20verify=…
Name=员工ID kind=ID StringLength=20 verify=…
Name=性别 kind=SexStringLength=2verify=…
Name=年龄 kind=ageintLength=3verify=…
Name=住址k ind=addrssStringLength=200verify=…M0(对象):员工：名字=张三 员工ID=100100 性别=男 年龄=21 Length=4 verify=（长度和数据类型的验证）
上面的例子用元模型描述应该是：
Role (角色-Table的概念或者类的概念)
{
id:EmployeeInfo
name:员工信息表
metaType: Role
parentId:root
context: { TableType：isMain }
}
Property
{
id:Name
name:名字
metaType:Property
parentId:EmployeeInfo
context: { dataType:String , dataLength:20 ,pk:false }
}
Property
{
id:ID
name:员工ID
metaType:Property
parentId:EmployeeInfo
context: { dataType:String , dataLength:8 ,pk:true }
}
Property
{
id:Sex
name:性别
metaType:Property
parentId:EmployeeInfo
context: { dataType:String , dataLength:2 ,pk:false }
}其他字段略。。。
我们可以看到，利用元模型固有的一些属性，我们很容易的描述出了我们的M1层的信息。实际的元模型属性远远比上面的复杂，但是我们有了一个初步的思路。
