DDD 概览

关注

发布于: 4 小时前

为什么写此系列文章

在笔者学习 DDD 的过程中，大部分文章通常都是在谈 DDD 的概念，理论，诚然这些很重要，但 DDD 的读者大多还是习惯与传统开发的方式，而 DDD 的思想与传统开发模式大为不同，当大量的理论铺面而来的时候，难免觉得无从着力，本系列文章希望通过一个实际系统的 DDD 案例,让读者对 DDD 的落地有一定的认识，认识的同时也会产生新的疑问，带着这些疑问在回头去学习 DDD 的系统理论，相信能够对读者起到帮助。

此章节希望读者对 DDD 有一些基本概念，在本章中不会深入到具体概念的细节，在《实现领域驱动设计》一书中 DDD 每个概念背后都有一套详细的设计原则，后续文章中我们将结合编码的同时将一些概念与读者一起描述但不会过多的深入设计原则。

什么是领域驱动设计?

领域驱动设计目前被大量的提及，那么什么是领域驱动设计呢？笔者在刚开始接触时被这个问题纠结了很久，随着持续的学习，搜索大家对 DDD 的总结，发现 DDD 很难用一句话简单的描述清楚，让读者可以理解其含义。因此关于这个问题的解释我们就稍微繁琐一点，在领域驱动设计中，领域可以理解为业务，领域专家就是对业务很了解的人，比如你想要做一个在线车票的售票系统，那么平时我们看到的售票员可能就是领域专家，在比如你已经在一个业务上做了 5 年研发了，经历了各种需求的迭代，讨论，你懂得比新来的产品，业务还多，那么你有可能就是你们公司的领域专家。领域驱动设计的核心就是与领域专家一起通过领域建模的方式去设计的我们的软件程序。

那么领域如何驱动设计？或者说业务如何驱动软件设计？

单纯聊这个问题很奇怪，我们平时开发不都是业务驱动的吗？是的，但仔细的琢磨一下我们的开发过程，你会发现其中的问题。我们在和业务（领域）专家讨论时,我们是想着将需求如何映射到代码上，还是想着应该创建那些表，改那些表字段才能满足需求呢？我们在拿到一个产品原型，需求清单第一步是写代码还是创建数据表呢？大多数时候答案是后者，因此我们实际是将面向业务开发转换为了面向数据开发。

那么 DDD 如何解决这个问题呢，答案是领域模型，我个人认为领域模型的核心是通过模型承载和保存领域知识，并通过模型与代码的映射将这些领域知识保存在程序代码中。==在传统的开发中，当业务被转换为一张张数据表时，丢失最多的就是领域知识。==

举个例子，大家都用过信用卡，假如用信用卡买了一瓶可乐，花了 3 块钱，那么信用卡的可用额度就会少 3 块钱。如果把这个需求映射为一个程序实现，在传统的开发模式中，会先创建一张用户资金账户的数据表，里面有用户的可用额度，当买了一瓶 3 块钱的可乐，就用可用额度减去 3 块，在把最新可用额度写回数据表。但是这里面忽略了一个问题，信用卡的每一笔消费都应该有记录，所以在这个场景中要扣除余额的同时还要记录一个账单的流水，而这个就是业务知识。当然你可能会说我在改资金账户表的时候在新增一条流水记录，然而当我们大脑里将业务映射为多个数据表的联动时，就已经不自觉的将程序的重心从业务转向了数据，而此时的领域知识被分散到不同的数据表中，就像被割裂了一样。