［需求］我们应当怎样做需求分析：领域驱动设计

Posted 2021-05-01 软件工程之思

2007年，世界级的软件分析大师Eric Evans发表了他的经典著作《领域驱动设计》，进而形成了一套独特的软件分析与设计方法，简称为DDD（Domain-Driven Design）。在领域驱动设计思想中，有许多是涉及到需求分析领域的先进方法，我把它归纳为有效建模、统一语言和持续学习。 

有人说：大师所站的高度实在太高了，是生活在太空里的，所以我们要追随大师就只有因为缺氧而死掉。我认为这句话说得非常生动，学习大师真的不是一件容易的事，把大师的思想落实到我们的工作中更难，常常还伴随着一些不小的风险，学习伊大师也是一样的。 

伊大师一上来就提出了要有效建模的思想，我当时立马就晕菜了。按照这个思想，我们应当在业务研讨会上，与客户讨论业务需求的时候就开始现场建模了。这！怎么可能呢？客户看得懂那些专业的、抽象的模型吗？我们能拿着模型与客户交流吗？这是不是在浪费时间？ 

的确，伊大师提出了有效建模思想，与其它很多诸如在会后分析整理时进行的原文分析方法大相径庭。同时，这个思想认为，我们应当与客户代表形成一种统一的语言，一种混合语言。这种语言，既有软件技术中的元素，又有业务领域中的术语，同时，它又是技术人员与业务人员都能理解的语言。使用这个语言，技术人员与业务人员就是在用同一语言在沟通与讨论问题，这种沟通的障碍就得以消除。 

道理简单实践难，什么是有效的建模，什么是统一的语言呢？经过无数的实践与尝试，我逐渐开始明白了。首先，什么是有效的建模呢？当我们作为非专业人员去看一个建筑设计师绘制的图纸时，我们一看就明白这是一栋楼房，那是一座桥梁，为什么？因为图纸形象生动，没有那么多专业术语，我们一看就明白了。软件中的设计图也是一样的道理。 

当我们站在技术人员的视角去绘制设计图时，客户必然看不懂，因为图中使用的都是专业的术语、专业的符号，表达的都是专业的设计思想。反过来，如果我们站在业务人员的视角去绘制设计图时，情况就不一样了。如果一个用例图，图中的功能都是客户日常经常做的业务操作，并且命名都是业务人员能够理解的业务术语，试问客户会不理解吗？同样，在领域模型中，我们按照客户的思路，运用客户的术语，去绘制一个一个的对象，按照他们的思路去描绘对象间的关系，描绘对象间的操作，他们真的就会看不明白吗？这说得似乎有一些抽象，我们举一个实际的例子吧。 

有一次，我与客户在讨论一个考核系统，首先客户描述着他们的需求： 
客户：我们这个考核系统是由许多个考核指标组成的，每个考核指标就标志着我们的某项工作的完成情况。每个考核指标中有一个分母数，标志某段时间所有应当完成的工作数量，有一个分子数，标志这段时间正确完成的工作数量，最后还有一个过错数，标志那些错误的，或者没有按时完成的工作数量。 
需求人员：为什么是分子分母？ 
客户：因为最后要计算正确率，用正确率来考核一个单位完成工作的情况。 
这样，我们在纸上绘制出一个考核指标，在属性中写下分母数、分子数、过错数、正确率。 

需求人员：那么每个考核指标都有一个过错判断标准了？ 
客户：当然啦，每个考核指标都有它的过错判断标准。一个考核指标可能会有多个过错行为，每一个过错行为都有各自的过错判断标准，任何一个过错了，这个执法行为就算过错啦。 
需求人员：先等等，你刚才提到执法行为了。执法行为和考核指标是什么关系？ 
客户：哦，执法行为嘛，就是执法人员对某个用户执行的一次业务操作。考核指标中的分母数就是所有执法行为的个数；分子数就是正确的执法个数；过错数就是错误的执法个数。 
这样，我们就绘制出这样一个草图： 

客户看了这个草图有些不同明白：过错类型是什么东西？ 
需求人员：过错类型就是某种类型的过错行为呀，它定义了某种过错行为，有它的过错判断标准。下面这个过错行为就是那些具体的过错，比如张三今天犯了什么错，李四明天犯了什么错。 
客户：哦，明白。这两个箭头怎么跟其它箭头不一样，后面还跟了个菱形框？ 
需求人员：哦，这代表的是包含关系，表示一个考核指标包含了多个类型的过错行为呀。 

经过一番交流，我们已经明白客户的意思了，客户也明白我们画的图了。大家对彼此的交流都比较满意。 

所有的爱情都是以浪漫开始的，需求分析也不如此。随着需求分析的不断深入，我们发现问题了。在这张图中，我们把执法行为与过错行为仅仅描述为一对多的包含关系，似乎没有什么特别的。但对大量考核指标具体需求的分析，我们才发现其实不是这样简单。当考核指标只有一种过错行为的时候，那非常简单，这个过错行为对就是对，错就是错。但当考核指标存在多种过错行为的时候，情况就复杂了，必须分成三种情况： 

1. 一个执法行为同时包含多种过错行为，每个过错行为就是一个考核点，任意一个考核点错了整个就判错，只有所有考核点都正确才判正确。这种情况就像填一个表单，所有数据项都填对了才算对，任意一个错了就算错，然后画出这样一个对象图： 

2. 虽然一个考核指标定义了多个过错行为，但它把所有执法行为分为多个类型，每个类型的执法行为只对应一个过错行为，这个过错行为对就是对，错就是错： 

3. 最后一种就是那些限期完成的考核指标，正确的行为只有一个：按时完成的行为，过错行为却有两个：逾期完成与逾期未完成。 

虽然图形有些复杂，但这正是代表了现实世界业务的复杂性。我们拿着这些图与客户进行了简单的描述，由于图中的所有元素都是用客户熟悉的术语描述的，因此他们很快就能够理解。同时，开发人员拿到这样一个图，很快就制订了四套不同的方案，来分别解决四种不同的情况。 

随后，在对这四种情况更加深入的分析时，我们发现第一种情况在计算过错数时似乎有一些问题。在第一种情况中，一个执法行为包含了多个过错行为，如果出现了过错，过错数算几？假如一个执法行为包含三个过错行为，如果都做对了，分子数算1；但假如有2个过错行为错了，过错数算2？还有那一个正确的行为呢？这似乎有些矛盾！当我们向业务人员提出这个问题时，他也有些懵了，这样的结果似乎是我们双方都没有预料到的。经过反复的思考与讨论，最后我们做出这样的决定：将原有的过错数拆分成过错户与过错数。在以上情况中，如果一个执法行为有2个过错行为错了，过错户为1，过错数为2。试想，如果不对需求进行如此深入分析与理解，能发现这样的问题吗？如果不及早发现这样的问题，是否会给项目后期带来巨大的风险？ 

应该说，从最初的粗浅认识，深入到后来对四种情况的认识，正是体现了DDD的另一个思想：持续学习。需求人员在开始一个新的管理系统的分析工作时，都有可能面临着一个全新的业务领域。在这个领域中，他们不可能一夜成为专家，也不必要成为专家。他们需要时间去学习领域知识，但这并不意味着学习所有的领域知识，而是与软件相关的领域知识。做财务软件，你不必考财务师，但你必须要学会与财务软件相关的财务知识。你对领域模型的认识被延伸到了整个软件生命周期中，包括之后一次一次的升级完善。你每认识深入一点儿，就可能会体现到你的分析设计中，并最终体现在开发的软件中。你对领域知识认识再深入一点儿，软件就再完善一分。