DDD学习笔录——领域驱动设计的常见误区(即错误的理解)

可以将DDD看成一种开发思想体系；它促成了一种新的以领域为中心的思维方式。

它是一种学习过程，而非最终目标，这就是DDD的最大优势。

任何团队都可以编写一个软件来满足一组用例的需求，但那些将时间和精力花在其正在处理的问题域中的团队则能够持续演化产品以满足新的业务用例。

DDD本身并非一种严格的方法论，而是必须与一些迭代式软件项目方法论结合使用以构建并演化一个有用的模型。

由此可见下面的这些理解，存在很大的误区：

1、战术模式是DDD的关键

这明显不对，DDD并不是一种面向对象的设计，也不是一种以代码为中心的思想体系或者模式语言。

DDD与其说是软件设计模式不如说是通过协作来解决问题的方法。其目的并非编写优雅的代码。

软件不过是DDD的一个构件而已。

2、DDD是一套框架

这一点可能我们现在也是这么错的理解的。那为何说它不是一套具体的框架呢？

DDD不需要一套特殊的框架或数据库。代码中实现的模型遵循POCO(纯老式的C#对象)原则，该原则确保模型完全没有任何基础代码以便不会出现干扰其以领域为中心的目的。虽然面向对象的方法论对于模型构造很有用，但这绝不是强制性的。

DDD在架构上具有不可知性，因为不存在你必须遵循的固定单一的架构样式以实现它。Evans的文章中介绍了一种分层架构样式，但这并非唯一的选项。架构样式可以变化，因为它们应该在有界上下文级别应用，而非应用程序级别。

3、DDD是一颗灵丹妙药

我本以为DDD可以让我成为大神，显然我要失望了，但还是要学完，至少不是毒药。

DDD可能需要付出大量努力，它需要迭代式开发方法论，以业务为向导以及聪明的开发人员。

所有的软件项目都能从DDD的分析实际中获益(例如提炼问题域)，也能从战略模式中获益(例如分离一个表示领域逻辑的代码模型)。不过，并非所有软件项目都需要DDD的战术模式来构建一个富领域模型。寻常的领域不需要先进复杂的模型，因为她们只有很少或者没有领域逻辑。

巴特西