领域驱动设计:软件核心复杂性应对之道_你在构建正确的软件吗？（上）

《领域驱动设计15年》第11章

作者：Alexey Zimarev

译者：王柏元

校审：徐培、钟敬

1. 引言

本文是《Hands-On Domain-Driven Design with .NET》一书的第一章

软件行业诞生于20世纪60年代早期，自那时起就日益增长。我们经常会听到这样的预言：总有一天所有的软件都会被开发出来，到那时我们便不再需要更多的软件开发人员。但这个预言从未应验。事实上，为了满足不断增长的用户需求，软件工程师的队伍日益壮大。

然而，从软件行业的早期开始，绝大多数的软件项目，不是远超预算，就是交付延期，甚至以失败告终。 根据Standish Group的2015年CHAOS报告统计，从2011年到2015年，IT项目的成功率仅停留在22％的水平，失败率超过了19％，其余的项目也是历经坎坷。这些数字令人惊讶。四十多年以来，尽管许多软件项目管理方法被开发出来，并作为“银弹”加以宣传，但成功项目的数量几乎没有变化。

定义任何一个IT项目成功的关键因素，是要理解所设计的系统要解决的问题。对于那些声称能解决问题，但其实是无效或低效的系统，我们已经司空见惯了。理解要解决的问题，也是精益创业方法的核心原则（由Eric Ries在Crown Publishing公司所出版的“The Lean Startup”一书中提出）。Scrum和XP软件开发方法，都推崇与用户进行沟通，并理解他们的问题。

Eric Evans 在其标志性的著作《领域驱动设计：软件核心复杂性应对之道》（Addison-Wesley公司2004年出版）中，创造了领域驱动设计（DDD）这个术语。该书出版十多年后，人们对于书中所描述的实践和原则的兴趣，开始呈指数级增长。有很多原因让它越来越受欢迎，但其中最重要的是，DDD介绍了软件从业人员怎样建立对用户需求的理解，并创造能够解决问题且卓有成效的软件系统。

2. 理解问题

很少有人把软件编写得能触达问题的核心。当然，我们可以仅仅为了好玩或学习新技术，来写一个宠物项目^[1]。但对于专业人士，构建软件的目的是帮助他人 “更好、更快、更高效” 地完成工作。不然的话，开发软件是没有意义的。所以，这意味着首先需要有一个打算去解决的“问题”。而问题在认知心理学中的定义，是当前状态和期望状态之间的障碍。

2.1. 问题空间与解空间

在 Human Problem Solving（1972，Englewood Cliffs，N.J：Prentice-Hall）一书中，Allen Newell 和 Herbert Simon 这两位作者对问题空间理论进行了概述。该理论指出，人类是通过在 问题空间（problem space）中寻找解决方案来解决问题的。问题空间描述了问题的初始状态和期望状态，以及可能出现的中间状态，它还可以包含一些定义问题背景的特定约束和规则。在软件行业中，活跃在问题空间中的人，通常是客户和用户。

每个现实中的问题我们都希望能找到一个解决方案。只要经过在问题空间中充分的探究，我们就可以大致勾勒出从初始状态达到期望结果之间所需采取的步骤。这些大概的步骤和关于解决方案的所有细节就形成了一个解空间（solution space）。

关于在实施过程中将问题空间与解空间彻底分离，有一个非常经典的案例——一个在太空中写字的故事。在20世纪60年代，人们发现由于缺乏重力，平常使用的圆珠笔在太空中无法使用。于是NASA开发了一支能在太空中写字的圆珠笔，花费了100万美元；而苏联则用了一些还能用的旧铅笔，就顺利地解决了这一问题，几乎不需要任何成本。

这个故事听起来如此可信以至于它至今依旧在流传，甚至还在电视剧《白宫风云》中被马丁·辛扮演的总统所引用。这不仅是因为我们已经对一些受政府资助的机构浪费资金的现象习以为常，更大程度是因为我们曾看到过许多这样的例子：某某某因为效率低下，或者对现实情况的误解，为了去解决一些本来并不存在的问题，而给本来的问题增加了许多不必要的复杂性。

实际上这个故事是虚构的，NASA也曾经尝试过使用铅笔来解决这一问题，但最后由于铅笔会产生微尘、碎屑，以及考虑到木质铅笔的易燃性（不适合在微重力、封闭的飞船中使用），从而放弃了这一方案。一家名叫“Fisher Pen”的私营公司利用投资，开发出一款我们现在知道的“太空笔”，NASA测试后决定采用，后来它也获得了苏联的订单而销往海外。它的价格对每个人都是一样的，每支仅仅需要2.39美元。

来源: "事实还是虚构?: NASA花费百万美金开发能在太空上书写的笔，苏联却使用铅笔" by Ciara Curtin, Scientific American

在这个故事中，可以发现关于问题空间和解空间的另一重点：尽管有些问题本身看起来很简单，但是如果附带一些约束条件，我们可以称为 非功能性需求，就会比初见时复杂得多。

直接跳到解决方案本身很简单，我们每个人对于解决日常问题都经验丰富，所以我们都善于迅速找到许多问题的解决方案。但是，Bart Barthelemy和Candace Dalmagne-Rouge在When You’re Innovating, Resist Looking for Solutions (2013, Harvard Business Review)这篇文章中告诉我们，直接思考相关的解决方案会让我们的大脑不去思考本来的问题是什么。相反，对于我们脑子第一次浮现出的解决方案，我们要思考得深入再深入，关注更多方面的细节，让它成为解决特定问题的越来越匹配的理想方案。

还有一个要考虑的点是在寻找特定问题的解决方案时，会有一个危险是把所有注意力都聚焦在一个解决方案上。这个方案可能不是最佳的，但是，是你基于以往的经验和当前对问题和其它因素的理解，在脑子里第一个蹦出来的。

“细化”方式和“探索”方式

这种寻找和选择方案的“探索”方式，会让我们花费更多的精力在探索多种可选方案上，但是通过这种方式得到的答案往往会更精确、更有价值。我们将在本章后面更深入地讨论第一种可行方案。

2.2. 需求出了什么问题

我们很多人熟稔软件需求理论。开发人员很少能与想解决问题的人有直接的沟通。通常情况下，是有一个专职人员，比如需求分析师、业务分析师或者产品经理，与客户进行沟通对话，然后以功能需求的形式来进行归纳。

软件需求的形式不一而足，可以从大型的软件需求规范说明书到更“敏捷”的方式比如用户故事。让我们看看下面的例子：

一个系统可以生成每天、每个酒店将会入住和退房的客人列表。

你会发现，这句话仅仅描述了解决方案。我们不可能知道系统的用户在做什么以及系统所要解决的问题是什么。可能还会定义更多的需求以完善该方案，但是对问题的描述却一直没有出现在功能需求中。

相反，用户故事能让我们更深入地了解用户想要什么。比如这个用户故事：“作为一个仓库管理员，我需要能打印库存报告，以便在缺货时可以订货”。但是，这个用户故事已经指定了开发应该做什么，它是在描述解决方案 。而实际的问题可能是用户希望有一个更高效的采购流程，让他们从不缺货。或者，他们需要一个先进的采购预测系统，以便他们能提高仓库的吞吐量而不堆积额外的货物。

软件需求可谓“臭名昭著”，以至于你在Google图片搜索“软件需求”时，第二条记录会是这张图片：

我们不会认为软件需求是毫无价值的，有很多优秀的分析师，他们制定了高质量的需求规范。但是要明白：软件需求几乎总是代表写这些需求的人对实际问题的理解。需要花费更多的时间和金钱来写出更高质量需求，这一错误观念在业界颇为盛行。

然而，精益和敏捷方法论越来越鼓励开发人员和用户之间的沟通。了解要解决的问题是什么，贯穿于参与构建软件整个过程的每一个角色，从终端用户，到开发和测试人员，它们在一起寻找解决方案，消除臆测、构建原型让用户评估 —— 这些实践正在被许多成功的团队采用，在本书中你会看到他们和领域驱动设计也息息相关。

（本篇章未完待续）

参考

1. ^ 这里指的是Pet Store（宠物店）项目。1999年，SUN公司创建了该项目以演示J2EE技术。后来，不同的人不断用不同的技术（如 .NET、Spring等）来实现Pet Store。因此这个项目就成了人们学习和演示新技术的一种手段。 ——译者注