何为领域驱动设计（DDD）

领域：

没有丰富的领域知识能做出复杂的银行业业务软件吗?没门。答案永远是否定的。那么谁 了解银行业业务?软件架构师吗?不，他只是在使用银行来保护他的财产安全，并且确保需要 钱的时候能够取出来;软件分析师吗?也不是，他只懂得在已获取到所有材料的情况下，对一 个给定的主题进行分析;软件开发人员?别难为他了。那么还有谁?当然是银行的从业者了。 银行业务系统被银行的内部人员和专家所熟知。他们知道所有的细节、所有的困难、所有可能 出现的问题、所有的业务规则。这些就是我们永远的起始点:领域。

 

模型：

模型是软件设计中最基本的部分。我们需要它，是因为能够用它来处理复杂问题。我们对 领域的所有的思考过程被汇总到这个模型中。这样甚好，但它必须要脱离开我们的头脑，如果 它始终停留在我们的头脑中，其实并不会有多大的作用，不是吗?我们需要就这个模型跟领域 专家进行交流，跟相关的设计人员进行交流，跟开发人员进行交流。模型是软件的根本，但我 们需要找到一些方法来表达它，与其他人交流这个模型。在这个过程中我们并不是孤立的，所 以我们需要彼此共享知识和信息，而且我们需要把它做得更好、更精确、更完整，没有二义性。 要做到这点有多种方式。一种方式是图形化的:图形、用例、绘画、图片等。另一种方式是文 字描述，我们会写下我们对领域的愿景。还有一种方式是使用语言，我们能够也应该创建一种 语言，来对与领域相关的特定问题进行交流。在以后的章节中我们会详细讲解它们，但要点就 是，我们需要用模型来交流。

 

代码设计：

软件设计有不同的方法，其中之一是瀑布设计方法。这种方法包含了一些阶段。业务专家 提出一堆需求同业务分析人员进行交流，分析人员基于那些需求来创建一个模型，然后将建模 的结果传递给开发人员，开发人员根据他们收到的东西开始编码。在这个方法中，知识只有单 一的流向。虽然这种方法作为软件设计的一个传统方法，这么多年来已经取得了某种程度上的 成功应用，但它还是有它的缺点和局限。主要问题是业务专家得不到分析人员的反馈信息，分 析人员也得不到开发人员的反馈信息。

另一种方法是敏捷方法学，例如极限编程(XP)。这些方法学是不同于瀑布方法的一些活 动，其产生的原因是很难预先确定所有的需求，特别是在需求经常变化的情况。要想预先创建 一个覆盖领域所有方面的完整模型确实非常困难。需要做出大量的思考，而且在初期常常无法 看到涉及到的所有的问题，也无法预见到设计中某些带有负面影响或错误的部分。敏捷方法试 图解决的另一个问题被称为“分析瘫痪”，团队成员会因为害怕做出任何设计决定而止步不前。 尽管敏捷方法的倡导者承认设计决定的重要性，但他们反对做出预先设计。相反，他们借助于 实现层面的灵活性，通过由业务涉众持续参与的迭代开发和很多重构，开发团队更多地学习到 了客户的领域知识，从而能够产出满足客户需要的软件。

 

通用语言：

领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足 领域的共同点，它很适合作为这种通用语言的构造基础。

使用模型作为语言的主干。要求团队在进行所有的交流时都使用一致的语言，在代 码中也是这样。在共享知识和推敲模型时，团队会使用演讲、文字和图形。需要确保团 队使用的语言在所有的交流形式中看上去都是一致的。因为这个原因，这种语言被称为 “通用语言”(Ubiquitous Language)。

 

模型转换为代码：

为了实现实现和模型之间的紧密捆绑，通常需要支持建模范型(例如面向对象编程) 的软件开发工具和语言。

面向对象编程来实现模型，因为它们基于同一个范型(即，面向对象)。面向 对象编程提供了对象的类、类之间的关联关系、对象实例、以及对象实例之间的消息通 信。面向对象编程语言使得在带有关联关系的模型对象与它们的编程对等物之间创建直 接的映射成为了可能。

 

模型驱动设计的基本构成要素：

模式和模式间关系的总图：

 

 

 

分层架构：

领域驱动设计的一个通用的架构解决方案包含了 4 个概念层:

用户界面/展现层	负责向用户展现信息以及解释用户命令
应用层	很薄的一层，用来协调应用的活动。它不包含业务逻辑。它也 不保留业务对象的状态，但它保留有应用任务的进度状态
领域层	本层包含关于领域的信息。这是业务软件的核心所在。在这里 保留业务对象的状态。对业务对象和它们状态的持久化被委托 给了基础设施层
基础设施层	本层作为其他层的支撑库存在。它提供了层间的通信，实现对 业务对象的持久化，包含对用户界面层的支持库等作用

 

实体：

值对象：有的时候我们需要包含一个领域对象的某些属性。我们对它是哪一个对象并不感兴 趣，而是只关心它所拥有的属性。用来描述领域的特定方面、并且没有标识符的一个对 象，叫做值对象。