1：知识消化的过程
知识消化的过程
先给一个典型的应用需求讨论场景。
和业务方不断探讨需求，用开发者的角度阐述问题并得到他们的纠正，在这个过程中学习领域相关的术语，然后建立双方都能接受的表达方式。
在得到双方认可的核心之后，开始编写最简单的原型，没有持久化没有界面使用假数据，关注逻辑和实体的关系。然后给需求方演示。
不断继续上述过程，最终将得到一个模型以及和模型紧密一致的核心原型。模型将很多同义词和语言描述中微小的差别做了统一，并排除了很多个和问题没有直接关联的事实。
当有新功能加入的时候，开发人员和领域专家会走查原先的模型，当无法表达某个重要场景的时候则继续按上述的方式创建新的模型或者修改原有模型，让模型提现领域知识。而在精化模型的过程中，代码也得到了演进。
什么是知识消化
知识消化的过程，就是从大量信息中探寻有用部分，不断尝试信息组织形式，努力查找对大量信息的表达最有效的简单视图，就是这样的过程。
原始信息在领域专家和现有用户的头脑中、在遗留系统的文档中、在同领域的其他项目中。
信息的形式也可能是项目文档、已有系统和数据、大量的讨论等等。
在知识消化的过程中，开发者被迫学习了重要的有业务原理，而不是进行机械的功能开发；领域专家被迫提炼自己的知识澄清自己的需求和解释使之更加全面和精准。
开发者和分析员的参与让模型更加严密抽象整洁，而领域专家的参与可以反映深层次的知识，对真正重要的东西做出抽象。这会是一个良性循环。
现阶段常见的情况
瀑布开发中：
业务专家和分析员讨论，分析员来抽象再将结果传递给开发者，开发者编写程序。只是流动是单向的无反馈的，因此不会有积累和迭代更新。分析员负责建立模型且仅仅基于业务专家的意见，即没解决程序员开发过程的困惑也没有得到程序开发过程问题的反馈。
某些迭代开发：
没有对知识的抽象也就无法建立知识体系。开发者仅仅听取需求完成代码，然后展示结果并找出下一个需求。如果程序员对领域知识不感兴趣，那么仅仅会机械的完成功能，而不会理解背后的原理。这样的开发是无法得到可扩展的系统的。
由程序员自发完成的建模：
如果没有领域专家的参与，那么模型可能会非常幼稚，只能做基本工作，而无法充分反映领域的现状。这一点在“深层次知识”的小结中会详述。
持续学习
团队可能重组拆散，外包出去的关键子系统可能只交回代码而不包括模型，使用电信的开发方式是可能代码和文档并不能很好的传递知识，一旦某种原因导致没有口头传递知识，知识就丢失了。
高效的团队需要有意识的积累知识并持续学习。
即要完善技术本身，也需要完善建立领域模型积累知识的技能。
早期成果虽然变动很大甚至保留下来的不多，但是早期工作还是很重要的。早期工作启动了知识消化的过程，使后期工作更加高效；开始使用公共语言方便沟通理解；形成了贯穿项目的反馈闭环。
注：走查，指一种非正式的代码评审活动，现在广泛应用于其他方面，一般指一步一步检查或分布讨论。
2：有效建模的要素
1）模型和现实的绑定
2）建立基于模型的语言。让所有人在一个概念体系中讨论。
3）丰富的领域知识
4）迭代：添加新概念，移除老概念，慢慢深入领域。
5）头脑风暴和实验：语言、草图、头脑风暴可以在讨论中演示、尝试、演化、汇集。当团队走查场景时，口头表达本身就是对模型的可行性测试。整个过程就是在训练这个模型本身。
3：深层次的知识
领域知识远不止名词和概念，活动和规则也是知识的核心元素。领域专家在解决现实问题时，
有太多的常识、最佳实践、默契等等来处理问题，所以在表达的时候往往意识不到隐藏信息的缺失，
也往往意识不到，他们认为简单的过程其实带有很多潜在的复杂性。而程序员则无从知道这些隐藏信息，除非真的碰到了并和领域专家一起确认。
书中的一个好例子：
最简单的集装箱预定流程模型中，就是来货装满。程序员的角度来看，其实这样就满足需要了。但是实际操作中可能出现超卖的情况，因为不是每个预定都最终到场。所以通常是允许超卖一部分的，超卖多少，如果超卖了确实不够装那么怎么处理。对于领域专家，这些都是常识，但是对于程序员则是完全无从知道的信息。
正是由于领域包含了这样那样的隐藏知识，所以软件专家需要同领域专家一起协同，不断澄清规则消除矛盾和歧义，并不断迭代模型本身。同时，由于领域专家不能通过代码来了解开发者究竟接收到了什么信息，因此开发者也需要用一种统一的预言来沟通，这又回到了模型上。
随着对领域知识的理解逐步加深，往往会丢弃开始看上去很重要的元素，或者切换他们的角度。
但是，真是因为现实的复杂性，那么考虑太多之后往往陷入另一个极端，做过分细致的设计导致复杂度过大。
第15章将讨论如何关注重点并隔离问题使当前问题最小化。
