不论你曾经听到过什么传言，演进式技术和敏捷技术绝不只是“编码加修复”的一个新名字。在开始构建之前，你仍然需要探索需求并完整地思考架构和设 计；在编码之前，你需要一种好的方式进行建模。图1.1展示了敏捷模型驱动开发（AMDD）的生命周期（Ambler 2004；Ambler 2002）。通过AMDD，你在项目开始时创建一个初始的高层模型，对你打算处理的问题域的总体范围进行建模，并对构建的可能架构进行建模。你通常会创建 的一个模型是“苗条的（slim）”概念/领域模型，该模型描述了主要业务实体以及它们之间的关系（Fowler and Sadalage 2003）。图1.2展示了一个简单财务公司的例子。这个例子所展示的细节程度是你在项目开始时所需要的，你的目标是尽早考虑项目中的主要问题，而不是立 即去调查那些无尽的细节——你可以以一种即时生产（JIT）的方式在将来再考虑这些细节。
 |
| 图1.1敏捷模型驱动开发（AMDD）的生命周期 |
 |
| 图1.2一个假想的财务公司的概念/领域UML模型 |
 |
| （点击查看大图）图1.3UML表示的详细物理数据模型（PDM） |
随着你对领域理解的加深，你的概念模型自然会演进，但是其细节程度会保持不变。细节将在你的对象模型（这可能是你的源代码）和物理数据模型中得到反 应。这些模型以领域概念模型为指导，与其他工件并行开发以确保一致性。图1.3展示了一个详细的物理数据模型（PDM），代表了在第3个开发周期末尾时对 模型的扩展。如果“循环0”用了一周的时间，这个时间通常适合那些开发周期少于1年的项目，开发循环是每两周一个循环，那么该PDM就是项目开始7周后得 到的。这个PDM反映了到此时为止项目的数据需求，以及一些遗留下来的约束条件。将来的开发循环中的数据需求会在那些开发循环中以一种JIT的方式进行建 模。
演进式数据建模并不容易。你需要考虑到遗留下来的数据约束条件，我们都知道，遗留的数据源通常是讨厌的野兽，会破坏没有留心它的软件开发项目。幸运 的是，好的数据专家知道他们机构中数据源的细微差别，这种经验能以JIT的方式加以应用，这和以串行的方式加以应用一样容易。你还需要应用明智的数据建模 惯例，正如敏捷建模的“应用建模标准”这一实践所建议的那样。演进式/敏捷数据建模的一个详细例子发布在www.agiledata.org/essays/agileDataModeling.html上。