我们意识到系统中存在的大量结构性问题，根源都是我们知识的结构问题。 在知识结构层面，我们有两个主要问题。
一、没有意识到知识需要拆分
大家有个印象，认为对业务知识掌握越全面越好。没有意识到这里面其实有个陷阱。业务知识越全面越好，其实指的是“了解”得越全面越好，而不是“掌握”得越全面越好。1
所以大家没有想到需要对知识进行有意识地拆分。也就是说没有想到：
知识需要结构。而且这个结构需要设计。
我们来看看我们需要什么样的知识结构。
首先，我们的知识结构要能降低负担，使人集中精力。每个人掌握的知识刚好可以完成手边的工作。而不需要掌握所有的知识，就像造车轮胎的工程师不需要关心车身油漆的工艺，更不需要关心油漆工业发展趋势。
其次，我们的知识结构要能制造适当的隔离。这样我们能解开知识间的耦合，有助于解决知识在全局的概念不一致，也有助于协调知识演进的步调。
第三，我们的知识结构要能减少关联风险。知识不可能不与其他知识关联，那么我们希望关联越明确越稳定越好。如果关联不停产生不停终结不停变化，那么谁也没办法保证每次都能正确完整地识别。
二、知识的结构来自于“产品线”
虽然大家并没有意识到需要关注知识结构。但知识结构其实已经自然存在了。我们团队的结构和需求驱动的研发过程决定了我们的知识结构直接来自于我们的“产品线”结构。2
以“产品线”分布的知识有显著的特点：
- “补丁”： 补丁指的是一个产品线涉及到的业务知识方面很多，而且在无法控制地不断堆积。只要功能集发生变化，更多业务知识就要堆积上来。
- “碎片”： 碎片是指一个方面的业务知识分散在不同的产品线上，这些业务知识的一致性很难保证。要想维护一套完整的业务规则，往往需要在各个产品线穿梭，不时进行跨产品线归纳。
这时候的情况类似于下图中Transaction Script的情况。
显然，来自于“产品线”的知识结构，不能满足我们上面谈到的对知识结构的要求。
