使用Jdon Framework进行模型驱动软件开发

相关讨论和连接：

不同层之间的对象关系

某人终于明白了什么叫模型驱动的一年，这样说如何？

今天上来看到这样一个话题，正与我目前所从事的研发工作有关：业务构建平台，也想借此阐述一下我对MDA的理解，有不对的地方，欢迎砸砖头。

J2EE已发展了多年，作为一套基础技术的规范，用来统一具体的实现，如果J2EE是针对底层技术层面的话，那MDA是针对上层业务系统的，是一套构建上层业务系统的方法，但该方法是否会发展成为规范，成为统一业务系统的开发标准，我们只能拭目以待，或者说需要我们各位的努力。

MDA通过使用模型语言（这种方式在目前为止是最自然的方式）来描述上层业务系统，包括数据、信息、模块、应用以及流程等等，从各种视角来“定义”业务系统，而不是基于J2EE技术Code或者搭建出来的，基于MDA的开发工具，可以把开发人员彻底从复杂的底层技术细节中解放出来（如J2EE技术），而把注意力集中在理解用户需求上面，而那些所谓的面向构建技术甚至是J2EE技术，都可以作为MDA背后具体的PIM或PSM的实现细节

当然，实现这样一套MDA业务构建平台是一个庞大的系统工程，我们的研发team已经在这方面经历了5年的历程，我们愿意和业界各层次的人来探讨这样的问题。

以前的讨论：业务构建平台

>可以把开发人员彻底从复杂的底层技术细节中解放出来（如J2EE技术），而把注意力集中在理解用户需求上面

zjsun非常精彩，希望借这个专题和您讨论一下，言语不周，敬请谅解。

MDA/DSM等想法是想产生一种高效编程效率，就象高级语言相对汇编语言的提高一样，现在建模人员（架构师或业务人员）在对业务分析之后，需要通过程序设计将其转为代码，这里有个过渡衔接，甚至不匹配的问题，就象OO和数据库都是解决同一个问题两种方式，存在不匹配，最终可通过O/R Mapping技术解决一样，在分析到实现这个环境也存在Mapping技术。

说实在，这几年软件发展真是一种Mapping技术发展，将都解决同一问题的不同解决之道进行衔接。

MDA/DSM是一种面向建模人员的语言或工具，而不是开发人员，现在的开发人员要么升格做建模人员；要么做Mapping技术的具体“焊工”（没有贬低意思，只是形象表达），“焊工”就是象集成电路生产线上将芯片的各个脚互相对应焊接在一起，建模和技术实现的Mapping也是这样，做好模型类图和具体代码的对应即可，最终通过控制软件测试质量来确保软件系统完成。

我的理解：借用2－8原则，MDA也只能解决80％的问题，另外的20％还是需要定制
MDA＝模型语言（UML）＋Transformation（Mapping）＋技术实现＝业务系统的80％＝100％－20％的定制

借用banq的比喻，如果把业务系统比作为电子产品，那么：
UML ＝ 电路图

生成工具 ＝ 生产线

基础库 ＝ 分立元件（如电阻、电容、电感等）
功能组件 ＝ 集成电路（如A/D模数转换集成电路等）
运行框架 ＝ 印刷电路板（如多层的PCB板）

业务定制脚本 ＝ 焊锡，甚至可能是飞线

引发大家继续思考...

DDD 其实尽量的将客户的业务逻辑能够用比较好的语言和模型来表达，使得与客户与程序员之间的沟通能够更加清晰， 领域模型相比与数据库模型他更能够表现事物的逻辑。

DDD 在OO中得到了一定的应用，但这不证明他只能在OO下应用， 重视DDD我很赞成的， 只有在好的领域模型的基础下，软件事物才会来的更加容易...

这也就是我现在不赞成软件工人的说法的缘故了， Ajax 在我看来他只是动态语言在web 应用上流行的一个体现，而领域模型是更多的是设计师们看到了软件的不确定性，才造成他的火热，但这只会局限在设计师们中间， 看看 vistal 为什么一拖再拖...是的，软件还不是螺旋时代， ajax 技术本身则更多的流行与 web 时代，流行与程序员们之间... 在我看来二者没有可比性.