领域驱动设计与模型驱动设计的关系

把领域东西落实到设计中，就是模型了

领域驱动设计强调有一个专门的领域层，领域层不只是模型，还包括与模型相关的用来完成业务逻辑的其他元素，如服务等。

将领域层作为多层架构中最重点的层面来关注，高于其他层次，比如表现层 持久层或JMS/EMAIL发送这些应用服务层。

突出业务领域是DDD区别与MDD模型驱动设计的一个重要标志，是其升华和高级部分。

MDD曾经在EJB2时代就已经存在流行，所以DDD应该比MDD更具设计水准。

哦，那就是说，
现在的领域层=模型驱动设计中单纯的模型+维护这些模型的完整性操作+模型之间的关联维护+提供模型访问的方法。
那么领域驱动设计就强调了在领域层内完成与软件领域相关的所有方方面面，包括领域对象的完整性约束，领域对象之间的相关关联，领域对象的生命周期等等，而与完成这些内容相关的技术，则是由基础层来提供，比如持久化，消息服务等等。
不知道我理解的是否正确。

另外还有个问题
在领域驱动设计书中，作者好像在前几章一直强调领域模型是领域专家，分析人员与开发人员相互交流的平台，但是后几章，作者的例子却是以uml图来表现领域对象，那么，如果领域专家，或者开发人员对uml不熟悉，是否可以采用其他的方式来表示，如果采用其他方式来表示，那么，在开发中还需要uml图么？

你对领域层理解应该和我是一致，不过不敢说是否正确，这要问祖师爷Evans，呵呵，其实学习理论主要是学习其思维方法，开拓眼界，也就是思考的乐趣所在啊。

分析人员一竿子通到设计层面，分析设计人员也可称为建模专家，或业务专家，业务专家和软件人员属于不同层面的，业务专家不懂软件语言，两者需要交流需要一个语言界面，目前UML比较适合了，如果两者都懂Java语言，用Java bean来表达沟通也可以。

现在又提出一种DSL语言，就是供业务专家使用的语言，这样业务专家又直接侵入软件人员的工作，使用DSL可以进行编程实现了，比如现在很火的RoR Groovy都号称是DSL，只是这样可能过犹不及，将软件人员彻底赶出软件领域好像和当初业务专家从软件人员手中夺权有些本质不同了。

所以，业务专家觉得UML已经不够用了，插手到软件细节，用起DSL了，那么业务专家自己的重点(领域建模)可能就不一定能干好，多元时代讲究分工专业化啊。

如果DSL流行起来，DDD会不会面临着被淘汰？

>如果DSL流行起来，DDD会不会面临着被淘汰？
楼上可能没有理解我们前面讨论的内容，正是因为有了DDD，DSL才会流行，DDD让分析人员参与设计，最后借助DSL，参与编程，让不懂软件的业务专家建设软件。

DSL如同UML，是一种工具，而DDD是设计思想。
设计思想只有不断发展进步深化，思想不会全部否定，而是站在前人思想上再进步，而工具则有可能随着思想进步，不断出现完全淘汰更换。

DSL只不过是DDD业务专家介入编程领域的一个途径，现在还有其他路径：如MDA和MDSD，下面总结一下几个流程：
DDD --->UML模型类图---> DSL代码
DDD --->UML模型类图--->MDA(可视化) -->Java或.NET代码
DDD --->UML模型类图--->MDSD(可视化)--->Java或.NET代码

这三条路都已经有成型成品出来，第一个是RoR或Grails等; 第二个是Borland的together；第三个是Sculptor等。

这三条路将来谁是主流，都是未知数，各大门派目前正在摇旗呐喊啊，这是目前软件技术发展的前沿。其中MDA/MDSD商业化可能性比较大，DSL目前在开源领域发展好像不错。国内很多厂商也推出可视化开发工具，可是都只是技术具体方面(表现层面)工具，而不是MDA/MDSD或DSL，只有开发出这个领域的工具或软件才是与国际最新水平站齐。

相关文章:
DSM/DSL：Domain-Specific Modeling
http://www.jdon.com/mda/dsm.html

[该贴被banq于2007年08月19日 11:49修改过]

>让不懂软件的业务专家建设软件

以前您说过使用DDD必须会设计会编程， 业务专家或领域专家不会设计和编程怎么能使用DDD来进行建设软件呢？他们又怎么会懂设计思想用DSL来进行建设？

这里有些概念我可能表达不是很准确，需要说明一下。

不懂软件，应该说不懂具体语言相关的技术，设计模式可以使用UML表达，因此设计模式或思想可以说是超越具体软件技术的。凡是可以使用UML表达的思想都可以说不属于具体软件技术。所以，业务专家可以不懂编程，但是懂设计思想或模式。

>以前您说过使用DDD必须会设计会编程, 业务专家或领域专家不会设计和编程
看上去矛盾，其实和选择的路径有关：
如果选择我前面讲的DDD-->DSL这条路，那么就必须学会简单的语言，如RoR或Grails这些DSL脚本语言；这就是使用DDD会设计会编程了

如果选择DDD-->MDA这条路，就无须学习具体编程语言，通过MDA等可视化界面进行详细设计(如together)，然后直接生成代码就可以，软件人员再对这些代码进行维护和tunning。这就是业务专家无需学习编程了。

这回明白了，非常感谢banq。

这里还要补充一点，也是我刚刚想到的:

RoR/Grails之类DSL性质的语言既然是针对不懂软件技术的业务专家，那么作为软件专家或软件高手的我们是否需要RoR/Grails之类的DSL呢？这是一个问题，对于软件初学者也许需要；对于软件专家则可能不需要，但是可能在软件专家解决一些小需求小问题可以派上用场。

当然，也可能存在既懂一点业务又懂一点软件的中间专家，DSL对他们也比较合适。

所以，从一定高度就可以把握RoR/Grails之类DSL语言定位，而不会出现跟风狂热或者排斥甚至慌乱。
[该贴被banq于2007年08月21日 10:01修改过]

谢谢各位老大们的回复，学到了不少的东西哦。

设计与实现（编码）之间的矛盾和阻抗已经存在很久了。这其实也正是人和机器之间的矛盾。
个人以为在计算机未实现高度智能的情况下，用自动生成代码这种方法还是无法解决软件的问题。
目前自动生成解决得比较好的，就是模型的CRUD。但现实中使用的系统，还是要解决很多模型间的复杂关系问题，这类问题需要深入钻研才能解决。除此之外，性能问题很关键，这类问题需要相当扎实的硬件、软件相关基础知识和实践。再有就是表示层问题，要切实满足客户需求，没有多年表示层的功力还是很难解决。

所以业务专家和程序员应互相尊重，互相理解，通力合作，才能解决好问题。
也就是说，业务专家要具备相关编程的知识，程序员也要掌握一定的设计能力。
而好的架构师正是经过多年实践后，二者的完美结合。

恩，深受启发，那模型驱动开发已经放弃了吗？其实我觉得DSL是更接近于测试驱动开发，走了另一个分支，XP;可以说一下MDD吗？javabean vs domain(dao)?