需求发生的『良性』『显性』的变化就是软件不断迭代的驱动力，因此我们积累的领域知识和模型也要适应这种变化。关于提炼知识和建模，Eric Evans 也总结了一套名为*模型探讨漩涡（https://www.domainlanguage.com/ddd/whirlpool/）的方法。
聚焦于问题域的难点，领域专家用实例（一系列步骤或者状态变化）对场景进行解释，与此同时，团队开始提炼模型或是审视当前模型是否可以解决这些问题；不断用领域专家描述的更多场景来检验模型的有效性；随时将有助于揭示场景的模型场景和模型一并记录成文档，不断进行修正；当团队获得了对问题域的理解，并设计了足够的模型后，应该用原型或是实验代码来对模型进行验证。
搞清楚业务变化的具体的探索模型（建模）的方式有许多，例如事件风暴工作坊（Event Storming）、用户故事地图（Story Mapping）、实例化需求（Specification By Example）。关于这些方法的综合运用，可以参考《DDD 15 年》中的一片总结《模型探索漩涡》（https://zhuanlan.zhihu.com/p/141804228）。这里不再赘述。
Eric Evans 强调建模漩涡并不是一种开发流程，却能够适用于各种迭代开发流程。无论是在软件开发生命周期的那个阶段，任何时候只要是模型出现问题，就应该跳转到建模的漩涡方法提炼领域知识。
无独有偶，在Eric Evans 提出 DDD 的同时期，另一种流行的软件开发方法论 RUP （https://en.wikipedia.org/wiki/Rational_Unified_Process）也特别强调迭代建模。RUP 将软件生命周期分为四个阶段：
构思阶段 ：包括用户沟通和计划活动两个方面，强调定义和细化用例，并将其作为主要模型。
细化阶段：包括用户沟通和建模活动，重点是创建分析和设计模型，强调类的定义和体系结构的表示。
构建阶段：将设计转化为实现，并进行集成和测试。
移交阶段：将产品发布给用户进行测试评价，并收集用户的意见，之后再次进行迭代修改产品使之完善。
听起来有些像传统的瀑布式软件开发方法，但是 RUP 的每个阶段也划分成了更小的迭代。而且我们可以看到，业务建模始终贯穿了其生命周期的四个阶段。
作为一种厚重的软件开发方法论，RUP 如今已不再流行，但是迭代建模的思想依然值得我们借鉴。我们应当抓住软件开发生命周期中任何和领域专家交流的机会，通过挑战和澄清，不断地完善领域知识和模型。
到现在为止，似乎探索模型的实践大部分和梳理需求的实践雷同（除了实践风暴工作坊），好像我们在梳理需求的同时就完善了领域模型（当然更新模型的可视化需要花费额外的时间）。但我们可能忽视了一个问题，如何保证代码实现也随着领域模型的完善而演进。在 Eric 的模型探索阶段中有提到用实验代码来验证模型，当代码能够和模型匹配上，自然应该进入代码仓库。除此之外还有其他的实践吗？
迭代建模是对现有模型的刷新，而模型最为关键的两个要素是领域对象和边界。领域对象都承担着业务上的职责，必须有明确的描述；而边界体现着高内聚低耦合（不同粒度的边界，内聚的原则不同），边界内外的依赖有着不一样的约束。描述职责和约束依赖应该是代码对领域模型的最佳体现。
