今天我们来聊聊领域驱动设计(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); 把模型作为精粹的知识,以用于传递。 这样做的好处是显而易见的: 理解了模型,你就会大致理解代码的结构; 在讨论需求的时候,研发人员可以很容易明白需要改动的代码,并对风险与进度有更好地评估; 模型比代码更简洁,毕竟模型是抽象出来的,因而有更低的传递成本。 模型驱动本身并不是什么新方法,像被所有人都视为编程基本功的数据结构,其实也是一系列的模型。我们都知道有一个著名的公式“程序 = 算法 + 数据结构”,实际上这也是一种模型驱动的思路,指的是从数据结构出发构造模型以描述问题,再通过算法解决问题。 在软件行业发展的早期,堆、栈、链表、树、图等与领域无关的模型,确实帮我们解决了从编译器、内存管理到数据库索引等大量的基础问题。因此,无数的成功案例让从业人员形成了一种习惯:将问题转化为与具体领域无关的数据结构,即构造与具体领域无关的模
领域驱动设计
![](https://img-home.csdnimg.cn/images/20240711042549.png)