DDD(Domain Driven Design) 领域驱动设计从理论到实践 一

前言

​     笔者作为一个数据科学家和数据系统架构师，最近被拉去负责构建业务中台；因此学习了业务系统设计相关技术和方法论。希望把学习所得分享给读者，希望大家指正，感谢！

​     ***“一个设计是一个被创造出来得事物，与之相关的是一个设计过程，我们将此过程称之为设计，不加任何修饰。还有一个动词意义的设计，即进行设计。这三者是紧密相关的，我相信在具体的环境中就不会混淆它们的含义了。”*** — Frederick P.Brooks,Jr. <<设计原本>>

​     领域驱动设计，DDD(Domain Driven Design) 定义了一系列概念和模式，帮助高效地进行符合业务需求的软件设计和开发。实际上，DDD并不是一个新词，早在2003年Eric Evan就在其DDD的开山之作中提出了领域驱动设计的概念。但在当时，似乎并没有引起很大的影响，最近由于互联网应用的业务逻辑日趋复杂，DDD终于赢得了其该有的重视。但请注意，DDD并不是解决一切问题的银弹，它有其使用场景，同时也有不适合使用的地方。后面我们将再次探讨这个问题。

​     笔者认为对于应对复杂业务系统来说，DDD的思想方法是有价值的，但是未必需要全盘按照DDD的方法论来进行设计和开发。使用者可以根据自身需求和情况来进行权衡和折中选择。值得注意的是，DDD首先不是关于技术的，它是关于讨论、聆听、理解、发现和提升业务价值的，而这些都是为了把知识集中起来、沉淀下来。

​     为了清晰的解释DDD的核心作用及其理念，笔者认为有必要遵循第一性原理：软件产品的底层逻辑是什么？它到底解决了什么本质问题。为了一步步揭示DDD关于这个问题的答案，本系列文章将会讨论以下问题

1. 软件系统解决的核心问题
2. 领域驱动设计解决了什么问题
3. 架构的演进及DDD架构
4. 领域驱动设计基本概念介绍
5. 实践：DDD战略设计
6. 实践：DDD战术设计
7. 总结和资源分享

一. 软件系统解决的核心问题

​     这个问题的答案似乎不言而喻，但是真要给出最权威和最全面的解释却一点儿也不简单。

什么是软件系统？

​     这里，笔者并不想照搬维基百科上定义。我们大白话解释一下：软件系统即为了解决某类问题的计算机程序及其相关组件，包括代码、程序、配置、文档等。

为什么是软件而不是硬件？

​     这个问题的解释方向有很多，但对于我们要讨论的主题而言，答案应该是：”应对变化“。软件在一开始开发时就应该知道，它的作用之一就是应对变化。我们应该把软件的功能变化看作是一种常态，按照一般的理解，计算机软件的改变以适应新的需求和场景时，其成本应该比较低才对。

计算机怎么解决人的问题？

​     这就需要一个软件模型，它是在软件开发设计阶段构造地对业务问题的一个抽象。它的主要作用就是把业务需求的问题空间映射到软件系统的解决方案空间，如下图：

关于这一点，在后面还要继续探讨。

​     总结一下，软件系统解决的核心问题就是以建立软件模型的方式把使用者需要解决的问题映射到计算机系统的解决方案，以计算机程序的方式运行且需要随时应对需求变化。

​     软件模型这个词比较抽象，看我们能否把它具体化一下。那么，这里的这个软件模型到底指的是什么呢？从它的作用来讲是把需求等问题空间映射到计算机程序视角的解决方案空间，目的是为了解决具体的业务问题。按照这种思路思考的化，称之为业务模型更为具体一些。

需求

业务模型

程序

到这里我们得到了软件系统两个重要的能力：1. 应对变化能力 2. 业务模型能力

二. 领域驱动设计解决了什么问题？

软件开发中的问题

​     在讨论这个问题之前，我们需要了解在软件开发中我们经常遇到什么问题。

1. 开发人员对业务需求理解不正确。

2. 业务人员或产品人员对需求描述不清晰。

3. 需求经常变化，使开发人员不堪重负。

4. 新的开发人员无法接手，或者周期很长。

5. 产品的长期迭代演进困难，在此过程中，经常发现产品的技术选型和架构问题。

   这里难以罗列所有可能的问题，只是梳理了最常见的问题。

什么是领域驱动设计

​     好，我们终于引出了正题：领域驱动设计。

​     首先，我们需要了解什么是领域驱动设计及其基本理念。

​     从字面上解读，领域驱动设计是以领域为中心的。领域(Domain)，从广义上讲既是一个组织所做的事情以及其中所包含的一切。商业机构通常会确定一个市场，然后在这个市场中销售产品和服务。每个组织都有其自己的业务范围和做事方式。这个业务范围以及在其中所进行的活动就是领域。当我们为某个组织开发软件时，所面对的就是这个组织的领域，我们在这个领域工作。例如，电商领域、放贷领域、供应链金融领域等等。

​     领域这个词承载了太多含义，领域驱动设计并不是想要为整个领域的业务系统创建单一的、内聚的、全功能的模型；经验告诉我们这是非常困难的，且失败率极高。通常一个领域会被划分为若干个子域，而某个子域通常关注整个业务系统的某个方面。例如，在电商领域中，可以划分出支付子域、产品目录子域、物流子域等等。

​     领域驱动是一种软件开发方法，其设计的思路就是以领域或者子域为核心构建可重用的、可扩展的领域模型，目标是创造一个可伸缩的、可测试的、组织良好的软件系统。

​     这里又出现一个新词 “领域模型”，它的含义与前面所讲的 “业务模型” 类似，其细微差别之处在于：领域模型特指在某个领域的业务模型，而且更偏重与计算机程序所表达和接受的模型。领域模型是一个领域业务逻辑抽象，它描述了领域的各个方面，可以用来解决该领域的相关问题。

从技术视角上看，领域模型表示为：

    一般情况下，软件系统的设计会遵循高内聚、低耦合的原则。关联性较强的模型聚集在一起称为高内聚；各个模块之间降低互相依赖，称为低耦合。但是到底如何得知什么功能和对象关联性强，而什么对象关联性弱呢？该如何分析呢？领域驱动设计给出了一个分析思路和方法，细节探讨笔者将在后面的文章中讨论。

未完，待续…
DDD(Domain Driven Design) 领域驱动设计从理论到实践 二
DDD(Domain Driven Design) 领域驱动设计从理论到实践 三
DDD(Domain Driven Design) 领域驱动设计从理论到实践 四
DDD(Domain Driven Design) 领域驱动设计从理论到实践 五
DDD(Domain Driven Design) 领域驱动设计从理论到实践 六
DDD(Domain Driven Design) 领域驱动设计从理论到实践 七
DDD(Domain Driven Design) 领域驱动设计从理论到实践 八
DDD(Domain Driven Design) 领域驱动设计从理论到实践 九