今天我们来聊聊领域驱动设计（Domain Driven Design，即 DDD）。 说起业务建模，领域驱动设计是一个绕不过去的话题。自从 Eric Evans 在2000后发布他的名著“Domain Driven Design：Tackling the Complexity in the Heart of Software”，领域驱动设计这一理念迅速被行业采纳，时至今日仍是绝大多数人进行业务建模的首要方法。 有意思的是，可能因为成书年代过于久远，大多数人并没有读过 Eric 的书，而是凭直觉本能地接受了领域驱动这一说法，或是在实践中跟随周围的实践者学习使用它。但是对于 Eric 到底在倡导一种什么样的做法并不了然。 所以今天这节课，我们要回顾一下领域驱动设计的要点和大致做法，从而可以更好地理解 DDD 从何处而来，以及 DDD 在其创始人的构想中是如何操作的。 领域模型对于业务系统是更好的选择 我们都知道，软件开发的核心难度在于处理隐藏在业务知识中的复杂度，那么模型就是对这种复杂度的简化与精炼。所以从某种意义上说，Eric 倡导的领域驱动设计是一种模型驱动的设计方法：通过领域模型（Domain Model）捕捉领域知识，使用领域模型构造更易维护的软件。 模型在领域驱动设计中，其实主要有三个用途： 通过模型反映软件实现（Implementation）的结构； 以模型为基础形成团队的统一语言（Ubiquitous Language）； 把模型作为精粹的知识，以用于传递。 这样做的好处是显而易见的： 理解了模型，你就会大致理解代码的结构； 在讨论需求的时候，研发人员可以很容易明白需要改动的代码，并对风险与进度有更好地评估； 模型比代码更简洁，毕竟模型是抽象出来的，因而有更低的传递成本。 模型驱动本身并不是什么新方法，像被所有人都视为编程基本功的数据结构，其实也是一系列的模型。我们都知道有一个著名的公式“程序 = 算法 + 数据结构”，实际上这也是一种模型驱动的思路，指的是从数据结构出发构造模型以描述问题，再通过算法解决问题。 在软件行业发展的早期，堆、栈、链表、树、图等与领域无关的模型，确实帮我们解决了从编译器、内存管理到数据库索引等大量的基础问题。因此，无数的成功案例让从业人员形成了一种习惯：将问题转化为与具体领域无关的数据结构，即构造与具体领域无关的模