J2EE已发展了多年，作为一套基础技术的规范，用来统一具体的实现，如果J2EE是针对底层技术层面的话，那MDA是针对上层业务系统的，是一套构建上层业务系统的方法，但该方法是否会发展成为规范，成为统一业务系统的开发标准，我们只能拭目以待，或者说需要我们各位的努力。
MDA通过使用模型语言（这种方式在目前为止是最自然的方式）来描述上层业务系统，包括数据、信息、模块、应用以及流程等等，从各种视角来“定义”业务系统，而不是基于J2EE技术Code或者搭建出来的，基于MDA的开发工具，可以把开发人员彻底从复杂的底层技术细节中解放出来（如J2EE技术），而把注意力集中在理解用户需求上面，而那些所谓的面向构建技术甚至是J2EE技术，都可以作为MDA背后具体的PIM或PSM的实现细节
当然，实现这样一套MDA业务构建平台是一个庞大的系统工程，我们的研发team已经在这方面经历了5年的历程，我们愿意和业界各层次的人来探讨这样的问题。
zjsun非常精彩，希望借这个专题和您讨论一下，言语不周，敬请谅解。
MDA/DSM等想法是想产生一种高效编程效率，就象高级语言相对汇编语言的提高一样，现在建模人员（架构师或业务人员）在对业务分析之后，需要通过程序设计将其转为代码，这里有个过渡衔接，甚至不匹配的问题，就象OO和数据库都是解决同一个问题两种方式，存在不匹配，最终可通过O/R Mapping技术解决一样，在分析到实现这个环境也存在Mapping技术。
说实在，这几年软件发展真是一种Mapping技术发展，将都解决同一问题的不同解决之道进行衔接。
MDA/DSM是一种面向建模人员的语言或工具，而不是开发人员，现在的开发人员要么升格做建模人员；要么做Mapping技术的具体“焊工”（没有贬低意思，只是形象表达），“焊工”就是象集成电路生产线上将芯片的各个脚互相对应焊接在一起，建模和技术实现的Mapping也是这样，做好模型类图和具体代码的对应即可，最终通过控制软件测试质量来确保软件系统完成。
MDA＝模型语言（UML）＋Transformation（Mapping）＋技术实现＝业务系统的80％＝100％－20％的定制
借用banq的比喻，如果把业务系统比作为电子产品，那么：
UML ＝ 电路图
生成工具 ＝ 生产线
基础库 ＝ 分立元件（如电阻、电容、电感等）
功能组件 ＝ 集成电路（如A/D模数转换集成电路等）
运行框架 ＝ 印刷电路板（如多层的PCB板）
业务定制脚本 ＝ 焊锡，甚至可能是飞线
引发大家继续思考...
DDD 在OO中得到了一定的应用，但这不证明他只能在OO下应用， 重视DDD我很赞成的， 只有在好的领域模型的基础下，软件事物才会来的更加容易...