一、前言

本篇文章会简要介绍领域驱动设计能做什么，以作为多篇介绍领域驱动设计文章的开篇。后面会使用领域驱动设计的英文缩写 DDD。之所以开篇介绍 DDD 能做什么，而不是介绍是什么，原因是后者答案很容易找，只需 Google 一下。而介绍 DDD 能做什么，则可以从实践的角度介绍学习和使用 DDD 的必要性。

整体而言，DDD 还是一门偏小众的技术，了解者比例不高，更多的人也还没有意识到它的重要性。这也是写此篇文章的一个重要原因。

当然，虽然全篇不会介绍什么是 DDD，但是一句话介绍还是少不了：领域驱动设计是一种思想，用来指导复杂的软件系统的设计。正如那本同名书的副标题 ——《软件核心复杂性应对之道》。所以，领域驱动设计的思想是值得每一位从事软件系统开发，尤其是业务系统开发的同学了解学习的。

接下来简单介绍一下 DDD 在软件开发各方面中所能起到的作用。

二、DDD 的作用

1. 需求讨论

软件开发的很多问题其实源于需求讨论阶段。需求讨论不清、对需求的误解，等等，都会从一开始就对软件开发造成负面影响。

那 DDD 如何可以解决这一个问题？DDD 解决这一问题的方法的核心是 Ubiquitous Language —— 通用语言。

DDD 指出，对业务知识抽象建模而形成的领域模型应当成为软件开发交流过程中使用的通用语言。对于同一个业务概念，需求文档和代码实现中应该使用同一个词语去表述。不仅表面上的命名需要一致，背后的含义也应当是一致的。

这么做原因在于，软件开发过程中，同一个词，在产品经理和工程师的脑中，可能有着不一致的含义和理解。虽说这种不一致一般不至于差出十万八千里，但在复杂的系统开发中，即便是细小的差异，经过需求的组合以及时间的积累，最终会导致比较大的差异。而这种差异会对后来的软件开发造成越来越大的麻烦。

而在软件开发中应用 DDD，则可以避免这种问题的发生。

2. 系统设计

现在的业务系统的开发，使用的技术有了很大的进步，但是很多系统的设计似乎同十几年前并没有太大差别。虽然大家所使用的语言，如 Java、Python、Javascript、Go 等，都或多或少的包含了面向对象的特性，但大部分程序还是以面向过程的思维被设计。而这会导致很多系统设计层面的问题，例如过于复杂、庞大的业务层。

我对系统设计的看法是：对于一个系统的整体设计，更多的应当是使用面向对象的思想，面向过程的思想更多的是应用在具体功能设计上。

在面向对象设计的实际应用方面，DDD 能够提供非常好的实践性指导。这就是 DDD 在系统设计方面的意义。

3. 接口设计

在我工作过的项目中，接口设计常常是一个难题。接口不同于代码实现，代码实现可以经常修改，但接口一旦发布就很难修改了。所以，接口的设计需要非常慎重的考虑。

如何设计接口呢？在这方面，REST 是一个很好的实践。当然我不是说 REST 能解决所有的接口设计问题，确实有很多接口不适合用 REST 设计，也有很多接口使用类似但非标准的 REST 接口形式设计。但我建议，在设计接口时请认真考虑 REST 风格。

在使用 REST 风格设计接口时，需要考虑的重要问题包括确定系统中有哪些 Resource、这些 Resource 之间的关系是什么？

其实 REST 接口中的 Resource 其实可以与领域驱动设计中的实体互相等同。如果一个系统设计使用了领域驱动设计，那确定 Resource，以及它们之间的关系也就不是难事。自然，设计出合理的接口也就变得更加容易。

五、小结

大家在讨论技术问题时，往往会关注新和大的话题，比如某种新技术、新框架，或者某某系统的高可用架构设计、双11、大促系统设计等等。

这样的题目显然更吸引眼球。虽然这些高大上的内容是大家在工作中需要考虑的内容，也很重要，但是不应因此忽视平时工作更常遇见的问题 —— 如何设计好复杂的业务系统。

如果不能解决好业务系统的复杂性问题，那些如高可用、高并发、多机房容灾等等的高大上的技术改进工作实施起来也会变得异常困难。最重要的是，如果整个团队被业务问题搞得焦头烂额时，还有多少精力和热情投入到技术改进工作呢？

所以，从上面这个角度讲，领域驱动设计解决的不仅是业务系统的复杂性问题。

对于前面讲到的内容，我会在后续的文章中做更详细的介绍。

欢迎大家关注我的个人公众号：

我的技术公众号“编走编想”