"天下武功唯快不破，无坚不摧" 这是功夫里的一句话。也应证了现在不断涌现的开放平台和应用平台，以及 ruby on rails、django等快速开发框架流行的现状。

    国内的应用平台基本都号称建模是MDA，这些个人认为有可取之处，但宣传成分大于实效。为什么这么说呢，因为模型还不够完善，虽然提到了业务，但未曾完全脱开技术，降低了门槛，但又设置了门槛。想如今，找个技术人员容易，找个业务人员也容易，找个两者都懂点的也不难，难在能将两者贯通的人太难找了。

     拿实体建模来言，不管是ruby on rails之流（直接就是技术建模，虽然不管数据库内具体的类型，还得管ruby类型，比物理建模进了一步，但离业务还有点距离)还是国内的应用平台，偏向于技术的较多点。比如要指定类型（String，double，...)这种类型，在实际业务领域中是让人迷惑的，问那些常年在业务一线的，你去问他"编号是int还是String啊，你认为D_ID这个字段名称如何啊？"，这不是有点2嘛。

     所以业务模型必须基于业务元素来描述，否则就会有点两不搭边的感觉。这让我想起多年前研究SAP的R3平台的事情来了。SAP的R3虽说是一个比较有历史的平台，但有些思想还是可以值得借鉴的。在R3中描述实体是基于数据元素的，而不是直接的物理（数据库)类型，而数据元素又是基于域的。可以这样理解，域就是父类（抽象类），而数据元素则是具体实现类，当你建立实体对象的时候，使用数据元素来描述其的属性，这个过程和我们建立一个car 它有name属性，而name属性的类型是'汽车型号国际标准'（它定义了长度，和规则及来源）是一样的。也就是说通过数据元素，它屏蔽掉了具体的物理属性（数据库类型，长度，检验规则等)，并赋予了其业务的含义。

    从物理模型到业务模型，增加一个业务元素或叫术语的桥梁，那么衔接就显得顺理成章了，而且两方面都会觉得比较爽。业务专家或业务领域的人，交流的都是他们所在领域的语言（也叫术语），搞技术的人员，只需要把这些术语的规则弄清楚，而不是整个业务。其它的都交给业务领域的人去处理吧，毕竟他们才知道如何去管理业务啊。

    至于如何处理业务模型和物理模型的映射，这里面的思想，个人以为就是“条条大路通罗马，吾取一条行之”。对于物理实现而言，同一个业务问题，可以有多种处理方法，而在做平台时候，选一种经过验证的（有经验程序员试验过的)方式来处理，少点coding的自由，换取将精力集中在业务处理上，不能不说是一种提高开发效率的方法，没有选择，其实也是一种选择。将有限的精力放在客户问题领域中，而不是开发技术问题域中，不快也难啊。

    言语乱了些，权当做个纪念。记下一些感悟吧。