DDD自问自答

  • DDD是否是把问题搞复杂了?大量CRUD再辅以工作流之类基本能解决大部分问题,何需DDD?

软件的本质是解决问题,解决问题的要义在于分解,面向过程与面向对象或者其它方式是问题的不同分解方法。

面向过程(结构化编程)通过算法来分解问题,面向对象通过对象交互(明确对象职责)来分解问题。

两者都是解决问题的方法,同一个问题用这两种方法都可以解决。相较来讲,当一个问题复杂到一定程度后,面向对象更有优势。

DDD是对如何使用好面向对象来进行设计、分析乃至开发的一种指导、规则甚至是约束。

两者其实没有谁比谁复杂之说,是否复杂,在于使用的人,如思维惯性、熟练程度等,一个熟悉习惯了DDD的人让他用事务脚本的方式去解决一个简单问题,完全有可能效率低于他直接用DDD的方式来解决问题的。

  • 为什么DDD在真实项目中不被接受?

DDD的目标之一是建立统一语言,这是业务专家与技术设计开发人员之间的沟通工具,往往以领域专家的术语为准。

这说明,向我们描述需求的人,一是此业务领域的专家,具有权威性,二是他在描述需求时,更多的是在讲述业务的组成,规则约束等,而不是希望将来系统提供的操作。

而在现实中,我们碰到的往往不是什么专家,很多时候甚至都不知道要的是什么。而在描述需求时,更多的是在讲述现有的或期望的操作过程,如填写什么,点击什么。

这就说明,我们第一没有,基本也无法建立统一语言。第二,我们得到的需求是过程化的,更倾向于算法与数据结构的,所以数据驱动或过程式的开发便自然而然了。

这种情况下,但问题具有一定复杂度时,如前面所说,这与熟练程度有关,作为设计开发人员,可以在内部以DDD的方式来设计开发,并建立统一语言,这有助于设计开发团队的沟通及对业务问题一致的理解,也有助于业务的分解实现。

  • 哪些更适合建立领域模型?

在平时的项目中,很大一部分功能往往是填写一个表单,走个工作流程,通过一些操作,改变些数据状态,最算得上业务的也就是些检查规则(如完整性检查,某个值是否在某个状态下指定的范围内等),这种建不建模型其实是无所谓的,DDD也好,数据驱动、界面驱动也罢,建的实体,写的代码也基本是相近甚至是相似的。

需要建立模型,往往是那种有一定交互体系,一整套完整规则,触发机制的,用户关心的不完全是界面上展现了什么,怎么操作,而是系统运行过程中各部分是否尽到职责,是否符合整个业务体系下制定的规范等。如《面向对象设计与分析》中举的水培系统,制定植物的培养计划,在温度达到一定临界点指定的时间范围内,根据计划,添加养分或者调整温度等。

这个例子离我们平时的企业开发比较远,平时的企业开发中,如安评安检系统,平时需要定期或不定期进行安全评价、安全检查,其中业务数据的变化达到一定指标后,产生危险点,发现危险点后需要预警,并且有些需要定期整改,复查等。

这种业务也是,用户已经不仅仅关心系统展现与操作,这些业务便是非常适合,需要建立领域模型的。

posted @ 2012-09-14 23:34  文野  阅读(624)  评论(2编辑  收藏  举报