简介

软件是一种被创建用来帮助我们处理现代生活中复杂问题的工具，它只是到达目的的一种方法，而这个目的通常就是非常实际和真实的事情。

软件必须是实际和有用的，否则我们不会花那么多时间和资源去创建它。这就使它和我们生活的某个方面有非常密切的联系。

软件设计是一门艺术，像其他艺术一样，它不能通过定理和公式以一门精确科学的方式被教授和学习。通过软件创建的过程，我们可以发现有用的规律和技巧，但是我们也许永远不能提供一个准确的方法，以满足从现实世界映射到代码模型的需要。

软件产品既包括设计和开发它的那些人的个人劳动，也包括致力于它发端和成长的那些人的某些领导力和洞察力。

完成软件设计的方法多种多样。在过去的 20 年中，软件产业发现和使用了多种方法创建它的产品，每一个都有自己的优点和不足之处。

本书的目的是专注介绍一个出现和发展了 20 多年但近几年才有所成果的设计方法：领域驱动设计。

何为领域驱动设计

软件开发也是一样。我们不能直接坐下来敲代码。当然也可以这样做，在开发价值不大的软件时。但我们不能用这种方法开发复杂的软件。

为了创建一个好软件，你必须知道这个软件究竟是什么。在你充分了解金融业务是什么之前，你是做不出一个好的银行业软件系统的，你必须理解银行业的领域 。

业务领域就是我们永远的起始点。

在启动一个软件项目时，我们应该关注软件涉及的领域。

软件的最 终目的是增进一个特定的领域。为了达到这个目的，软件需要跟要 它服务的领域和谐相处，否则，它会给领域引入麻烦，产生障碍、 灾难甚至导致混乱等。

我们怎样才能让软件和领域和谐相处呢？

最佳的方式是让软件成为领域的反射（映射）。软件需要具现领域里重要的核心概念和元素，并精确实现它们之间的关系。软件需要对领域进行建模。

所以我们从领域开始着手。接下来要做什么呢？

领域是世界中的某 些事物，不要企图能轻而易举地捕获它们，以为敲几下键盘就能出 来代码。我们需要建立领域的抽象。当我们跟领域专家交流时，我 们会学到好多领域知识，但这些未加工的知识不能被容易地转换成 软件构造，除非我们为它建立一个抽象——在脑海中建立一个蓝 图。开始时，这个蓝图总是不完整的，但随着时间的推移，经过不断的努力，我们会让它越来越好，让它看上去越来越清晰。

这个抽象是什么？它是一个模型，一个关于领域的模型。

按照 Eric Evans 的观点，领域模型不是一幅具体的图，它是那幅图要极力去传达的 那个思想。它也不是一个领域专家头脑中的知识，而是一个经过严格组织并进行选择性抽象的知识。一幅图能够描绘和传达一个模 型，同样，经过精心编写的代码和一段英语句子都能达到这个目 的。

模型是软件设计中最基础的部分。我们需要它，是因为能够用它来 处理复杂问题。我们对领域的所有的思考过程被汇总到这个模型 中。

软件设计有不同的方法，

其中之一是瀑布设计方法。这种方法包含 了一些阶段。

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

另一个方法是敏捷方法学。

本书描述了领域驱动设计的原则，应用这些原则会增进对领域内复杂问题进行建模和实现的开发过程能力。领域驱动设计结合了设计和开发实践，展示了设计和开发如何协同工作以创建一个更好的解 决方案。优良的设计会加速开发的过程，而开发过程中的反馈也会 进一步优化设计。

构建领域知识

通过与领域专家的交谈，软件设计人员的分析型思维会帮助他挖掘出一些领域中的关键概念，并且帮助构建出可用于将来讨论用的结构，我们将在下一章中看到这种结构。

作为软件方面的专家（软件 架构师和开发人员）和领域专家，我们会在一起创建领域的模型， 这个模型会体现两个专业领域的交汇。这看上去是个很消耗时间的 过程，并且确实如此，但是它也应该被这样做，因为软件的最终目 的是去解决真实领域中的业务问题，所以它必须和领域完美结合。

通用语言

对通用语言的需要

通过前一章的案例，我们认识到由软件专家和领域专家通力合作开发出一个领域的模型是绝对需要的，但是，那种方法通常会由于一些 基础交流的障碍而存在难点。

为克服这种交流方式的不同，在建立模型时，我们必须通过沟通来交换对模型和模型中涉及到的元素的想法，应该如何连接它们，哪些是有关的，哪些不是？在这种层次上的交流对一个成功的项目而 言是极为重要的。如果一个人说了什么事情，其他的人不能理解， 或者更糟的是错误理解成其他事情，又有什么机会来保证项目成功 呢？

在讨论模型和定义模型时，我们确实需要讲同一种语言。

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

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

构建一个类似这样的语言会得到一个清晰的结果：模型和语言相互密切关联。一个对语言的变更会变成对模型的变更。

我们已经看到了语言是如何在整个团队中被共享的，也看到了它是如何帮助我们构建知识和创建模型的。我们应如何使用这些语言呢，只是语言交谈吗？

UML 很适合用来构建模型，它也真是一种很好的记录关键 概念（如类）和表现它们之间的关系的工具。

文档。一个明智的沟通模型的方式是创建一些小的 图，让每副小图包含模型的一个子集。

模型驱动设计

软件开发过程的重点：它必须以业务领域为中心。 我们说过让模型植根于领域、并精确反映出领域中的基础概念是建立模型的一个最重要的基础。

通用语言应该在建模过程中广泛尝试以推动软件专家和领域专家之间的沟通，以及发现要在模型中使用 的主要的领域概念。建模过程的目的是创建一个优良的模型，下一 步是将模型实现成代码。

一个更好的方法是紧密关联领域建模和设计。模型在构建时就考虑到软件和设计。开发人员会被加入到建模的过程中来。主要的想法 是选择一个能够恰当在软件中表现的模型，这样设计过程会很顺畅 并且基于模型。代码和其下的模型紧密关联会让代码更有意义并与 模型更相关。

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

面向对象编程非常适合对模型的实现，因为它们基于同一个范型。 面向对象编程提供了对象的类和类之间的关联关系、对象实例、以 及对象实例之间的消息通信。面向对象编程语言让建立模型对象、对象关系与它们的编程副本之间的直接映射成为可能。