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. 总结和资源分享

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

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

什么是软件系统？

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

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

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

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

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

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

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

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