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

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

　　虽然图形有些复杂，但这正是代表了现实世界业务的复杂性。我们拿着这些图与客户进行了简单的描述，由于图中的所有元素都是用客户熟悉的术语描述的，因此他们很快能够理解。同时，开发人员拿到这样一个图，很快制订了四套不同的方案，来分别解决四种不同的情况。
　　随后，在对这四种情况更加深入的分析时，我们发现第一种情况在计算过错数时似乎有一些问题。在第一种情况中，一个执法行为包含了多个过错行为，如果出现了过错，过错数算几？假如一个执法行为包含三个过错行为，如果都做对了，分子数算1；但假如有2个过错行为错了，过错数算2？还有那一个正确的行为呢？这似乎有些矛盾！当我们向业务人员提出这个问题时，他也有些懵了，这样的结果似乎是我们双方都没有预料到的。经过反复的思考与讨论，后我们做出这样的决定：将原有的过错数拆分成过错户与过错数。在以上情况中，如果一个执法行为有2个过错行为错了，过错户为1，过错数为2。试想，如果不对需求进行如此深入分析与理解，能发现这样的问题吗？如果不及早发现这样的问题，是否会给项目后期带来巨大的风险？
　　应该说，从初的粗浅认识，深入到后来对四种情况的认识，正是体现了DDD的另一个思想：持续学习。需求人员在开始一个新的管理系统的分析工作时，都有可能面临着一个全新的业务领域。在这个领域中，他们不可能一夜成为专家，也不必要成为专家。他们需要时间去学习领域知识，但这并不意味着学习所有的领域知识，而是与软件相关的领域知识。做财务软件，你不必考财务师，但你必须要学会与财务软件相关的财务知识。你对领域模型的认识被延伸到了整个软件生命周期中，包括之后一次一次的升级完善。你每认识深入一点儿，可能会体现到你的分析设计中，并终体现在开发的软件中。你对领域知识认识再深入一点儿，软件再完善一分。