迭代式模型较之瀑布模型有很大地改进，因为它允许变更、优化系统需求，整个迭代过程实际上就是与领域专家的合作过程，通过向客户演示迭代所产生的系统功能，从而及时获取反馈，并逐一解决迭代演示中出现的问题，保证系统向着合乎客户需求的方向演化。因而，迭代式模型往往能够解决早期计划不足的问题，它允许在发现缺陷的时候，在需求变更的时候重新设计、重新编码并重新测试。
无论采用何种开发模型，与领域专家的合作都将成为项目成败与否的关键。这基于一个软件开发的普遍真理，那就是世界上没有不变的需求。一句经典名言是：“没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。”一语道尽了软件开发的残酷与艰辛！
那么应该如何加强与领域专家的合作呢？James Carey和Brent Carlson根据他们在参与的IBM SanFrancisco项目中获得的经验，提出了Innocent Questions模式，其意义即“改进领域专家和技术专家的沟通质量”。在一个项目团队中，如果我们没有一位既能担任首席架构师，同时又是领域专家的人选，那么加强领域专家与技术专家的合作就显得尤为重要了。毕竟，作为一个领域专家而言，可能并不熟悉软件设计方法学，也不具备面向对象开发和架构设计的能力，同样，大部分技术专家很有可能对该项目所涉及的业务领域仅停留在一知半解的地步。如果领域专家与技术专家不能有效沟通，则整个项目的前途就岌岌可危了。
Innocent Questions模式提出的解决方案包括：
（1）选用可以与人和谐相处的人员组建开发团队；
（2）清楚地定义角色和职权；
（3）明确定义需要的交互点；
（4）保持团队紧密；
（5）雇佣优秀的人。
事实上，这已经从技术的角度上升到对团队的管理层次了。就好比篮球运动一样，即使你的球队集合了五名世界上最顶尖最有天赋的球员，如果各自为战，要想取得比赛的胜利依旧是非常困难的。团队精神与权责分明才是取得胜利的保障，软件开发同样如此。
与领域专家合作的基础是保证开发团队中永远保留至少一名领域专家。他可以是系统的客户，第三方公司的咨询师，最理想是自己公司雇佣的专家。如果项目中缺乏这样的一个人，那么我的建议是去雇佣他，如果你不想看到项目遭遇“西伯利亚寒流”的话。
确定领域专家的角色任务与职责。必须要让团队中的每一个人明确领域专家在整个团队中究竟扮演什么样的角色，他的职责是什么。一个合格的领域专家必须对业务领域有足够深入的理解，他应该是一个能够俯瞰整个系统需求、总揽全局的人物。在项目开发过程中，将由他负责业务规则和流程的制定，负责与客户的沟通，需求的调研与讨论，并于设计师一起参与系统架构的设计。编档是领域专家必须参与的工作，无论是需求文档还是设计文档，以及用例的编写，领域专家或者提出意见，或者作为撰写的作者，至少他也应该是评审委员会的重要成员。
规范业务领域的术语和技术术语。领域专家和技术专家必须在保证不产生二义性的语义环境下进行沟通与交流。如果出现理解上的分歧，我们必须及时解决，通过讨论确立术语标准。很难想象两个语言不通的人能够相互合作愉快，解决的办法是加入一位翻译人员。在领域专家与技术专家之间搭建一座语义上的桥梁，使其能够相互理解、相互认同。还有一个办法是在团队内部开展培训活动。尤其对于开发人员而言，或多或少地了解一些业务领域知识，对于项目的开发有很大的帮助。在我参与过的半导体领域的项目开发，团队就专门邀请了半导体行业的专家就生产过程的业务逻辑进行了全方位的介绍与培训。正所谓“磨刀不误砍柴工”，虽然我们消费了培训的时间，但对于掌握了业务规则与流程的开发人员，却能够提升项目开发进度，总体上节约了开发成本。
加强与客户的沟通。客户同时也可以作为团队的领域专家，极限编程的现场客户原则是最好的示例。但现实并不都如此的完美，在无法要求客户成为开发团队中的固定一员时，聘请或者安排一个专门的领域专家，加强与客户的沟通，就显得尤为重要。项目可以通过领域专家获得客户的及时反馈。而通过领域专家去了解变更了的需求，会在最大程度上减少需求误差的可能。
5.2 业务逻辑层的模式应用