DDD自问自答

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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