领域驱动与模型驱动

  原文参见:
http://www.domaindrivendesign.org/discussion/blog/evans_eric_ddd_and_mdd.html
  标题:Domain-Driven / Model-Driven
  作者:Eric Evans
      February 4, 2004

  译序
  这是第一次翻译老外写的文章,以前看国人翻译的文章总是嗤之以鼻,认为文章怎么翻译的这么烂,还是看原文好(其实自己看原文时总是看个大概).真正自己动笔翻译时,才知道,要想把每一个细节都翻译的到位,不仅需要深厚的中英文文学功底,还需要对相关技术的熟悉,而我似乎这三者都做得不够,以至于自己翻译完之后都看不懂,更不用说什么翻译的信达雅了.看来,翻译还有很长一段路要走.所幸,通过翻译更加能够理解相关技术的所以然.
  希望自己在翻译的过程当中沿着信达雅的层次往上走,不段的完善自己在英文与技术层次上的功能.

  领域驱动设计与模型驱动设计之间有什么区别呐?因为这两个术语在名称上相近,概念上也有重叠,所有常常被混淆了.但是它们是两个截然不同又相互补充的程序开发的方法.

  领域驱动设计基于一个基本的前提:即程序开发的核心是主题知识(译:knowledge of the subject matter)以及找出一些有用的方法来理解这些主题知识. 需要我们去处理问题的复杂性在于领域本身,而不是技术架构,用户接口,甚至那些特殊的特性.这就意味着所有的设计都是关于我们对最本质的业务概念理解,同样也可以通过程序设计是否基于那些核心的业务概念来判断所有其它的程序是否合理.
 
  为了达到这一点,领域专家与程序专家必须一起寻求一些方法,组织主题知识为程序开发的目的服务.他们必须专注于他们的主题,让主题来引导他们,为构建程序第一步即是描述和理解领域设定优先级.他们必须挖掘出一些核心的规则,忽略那些肤浅的方面.

  把知识提炼成一组明晰的概念是一个建模的过程.这些模型存在于一个团队语言当中,而基于这些语言的每一次会议都是一个建模会话.所以领域驱动设计不可避免的会导致建模,是因为建模是一个我们获得复杂领域理解的一个方法.

  当前,有些团队可能会写一些事务脚本或者其它形式的非模型驱动程序,并且他们对领域的理解可能是有价值的,只要他们的程序员本身是共享那些知识的.

  但是,当这些模型仅仅悬浮在空中,他们没有很好的掌握的时候. 每一个程序遇到的问题必须在这种设计下解决. 这就存在一种风险:模型变得没有意义甚至会误导.所以,我们需要给出一个模型的轮廓.

  模型驱动设计实际上是基于一组概念构建的程序.例如,一个UI框架如果一些UI概念,比如窗口,菜单等与实际的程序构建相关联,则可以称这个UI框架是模型驱动设计的.有些UI框架是这样设计的,而另外一些只是简单的提供了一些函数来达到这些效果.

  所以在UI和基础架构中模型驱动设计可以被归类技术问题.全是,这只是模型驱动设计在那些让开发项目起飞领域方面的应用.当开发人员专注于领域,与领域专家拍档咀嚼知识,通过无所不在的语言建立的共享模型的练习,他们脑海中提炼并形成一个共享模型.模型驱动设计使用那些模型嵌入到程序的每一个角落.最后,这些反馈循环会在实现与领域学习之间关闭.

  在模型驱动设计中,设计不仅仅是基于模型,一个模型也可以用来满足设计与实现的考虑.通过迭代同时解决了这两个限制.这就部分的反映出,我们特定硬件或者程序语言或者底层架构的限制.这是本质的,但是一些更加基础的也会发生.编程显示了精妙性,但在逻辑中重要的错误是那些从来不会被关注的(至少不会是有损效率的).在在编写模型驱动设计这些困难被解决后,程序员就会提炼领域相关的思想来解决这些错误.那些坚持模型驱动设计的团队意识到代码的更改就是模型的更改.小的异常可能是一个大的模型insights的提示.

  在领域驱动设计中,我写了一个经历:在大的金融交易中,分配剩余的一分钱的硬币会导致复杂的新insights和主要模型的重新设计.在过程设计中,这可能会发生,但在我们头脑和语言中,这很少发生,因为领域思想之间对应的代码的耦合度比较低.所以说,这两种模型的思考方式是相互独立的.

  这是为什么模型驱动设计是领域驱动设计一个不可缺少的自然伙伴.它允许领域专家和程序员通过自然语言,或者程序本身,甚至是终端客户来达成对领域的深度理解 -- 以及所有回归的方式.