2007年，的软件分析大师Eric Evans发表了他的经典著作《领域驱动设计》，进而形成了一套独特的软件分析与设计方法，简称为DDD（Domain-Driven Design）。在领域驱动设计思想中，有许多是涉及到需求分析领域的先进方法，我把它归纳为有效建模、统一语言和持续学习。
　　有人说：大师所站的高度实在太高了，是生活在太空里的，所以我们要追随大师只有因为缺氧而死掉。我认为这句话说得非常生动，学习大师真的不是一件容易的事，把大师的思想落实到我们的工作中更难，常常还伴随着一些不小的风险，学习伊大师也是一样的。
　　伊大师一上来提出了要有效建模的思想，我当时立马晕菜了。按照这个思想，我们应当在业务研讨会上，与客户讨论业务需求的时候开始现场建模了。这！怎么可能呢？客户看得懂那些专业的、抽象的模型吗？我们能拿着模型与客户交流吗？这是不是在浪费时间？
　　的确，伊大师提出了有效建模思想，与其它很多诸如在会后分析整理时进行的原文分析方法大相径庭。同时，这个思想认为，我们应当与客户代表形成一种统一的语言，一种混合语言。这种语言，既有软件技术中的元素，又有业务领域中的术语，同时，它又是技术人员与业务人员都能理解的语言。使用这个语言，技术人员与业务人员是在用同一语言在沟通与讨论问题，这种沟通的障碍得以消除。
　　道理简单实践难，什么是有效的建模，什么是统一的语言呢？经过无数的实践与尝试，我逐渐开始明白了。首先，什么是有效的建模呢？当我们作为非专业人员去看一个建筑设计师绘制的图纸时，我们一看明白这是一栋楼房，那是一座桥梁，为什么？因为图纸形象生动，没有那么多专业术语，我们一看明白了。软件中的设计图也是一样的道理。
　　当我们站在技术人员的视角去绘制设计图时，客户必然看不懂，因为图中使用的都是专业的术语、专业的符号，表达的都是专业的设计思想。反过来，如果我们站在业务人员的视角去绘制设计图时，情况不一样了。如果一个用例图，图中的功能都是客户日常经常做的业务操作，并且命名都是业务人员能够理解的业务术语，试问客户会不理解吗？同样，在领域模型中，我们按照客户的思路，运用客户的术语，去绘制一个一个的对象，按照他们的思路去描绘对象间的关系，描绘对象间的操作，他们真的会看不明白吗？这说得似乎有一些抽象，我们举一个实际的例子吧。
　　有一次，我与客户在讨论一个考核系统，首先客户描述着他们的需求：
　　客户：我们这个考核系统是由许多个考核指标组成的，每个考核指标标志着我们的某项工作的完成情况。每个考核指标中有一个分母数，标志某段时间所有应当完成的工作数量，有一个分子数，标志这段时间正确完成的工作数量，后还有一个过错数，标志那些错误的，或者没有按时完成的工作数量。
　　需求人员：为什么是分子分母？
　　客户：因为后要计算正确率，用正确率来考核一个单位完成工作的情况。
　　这样，我们在纸上绘制出一个考核指标，在属性中写下分母数、分子数、过错数、正确率。
　　需求人员：那么每个考核指标都有一个过错判断标准了？
　　客户：当然啦，每个考核指标都有它的过错判断标准。一个考核指标可能会有多个过错行为，每一个过错行为都有各自的过错判断标准，任何一个过错了，这个执法行为算过错啦。
　　需求人员：先等等，你刚才提到执法行为了。执法行为和考核指标是什么关系？
　　客户：哦，执法行为嘛，是执法人员对某个用户执行的一次业务操作。考核指标中的分母数是所有执法行为的个数；分子数是正确的执法个数；过错数是错误的执法个数。
　　这样，我们绘制出这样一个草图：

 　　客户看了这个草图有些不同明白：过错类型是什么东西？
　　需求人员：过错类型是某种类型的过错行为呀，它定义了某种过错行为，有它的过错判断标准。下面这个过错行为是那些具体的过错，比如张三犯了什么错，李四明天犯了什么错。
　　客户：哦，明白。这两个箭头怎么跟其它箭头不一样，后面还跟了个菱形框？
　　需求人员：哦，这代表的是包含关系，表示一个考核指标包含了多个类型的过错行为呀。
　　经过一番交流，我们已经明白客户的意思了，客户也明白我们画的图了。大家对彼此的交流都比较满意。
　　所有的爱情都是以浪漫开始的，需求分析也不如此。随着需求分析的不断深入，我们发现问题了。在这张图中，我们把执法行为与过错行为仅仅描述为一对多的包含关系，似乎没有什么特别的。但对大量考核指标具体需求的分析，我们才发现其实不是这样简单。当考核指标只有一种过错行为的时候，那非常简单，这个过错行为对是对，错是错。但当考核指标存在多种过错行为的时候，情况复杂了，必须分成三种情况：
　　1. 一个执法行为同时包含多种过错行为，每个过错行为是一个考核点，任意一个考核点错了整个判错，只有所有考核点都正确才判正确。这种情况像填一个表单，所有数据项都填对了才算对，任意一个错了算错，然后画出这样一个对象图：