图3，“应保留的”与“临时的”敏捷模型

　　应保留的模型

　　在不同的情况下(人员数量、系统的重要度、需求的稳定程度、是否企业级系统或者嵌入式系统)，应保留的模型种类也不同。基于我的经验来看，以下几种模型可以成为应保留的模型：

　　架构的类图/包图

　　领域模型的类图/实体关系图

　　关键用例的用例图 + 时序图/协作图

　　虽然我们主要使用的是UML方式，但你也不必刻意遵守严格的UML规格。之所以选择它是因为它提供了种类丰富的标准图形，并且关于它的各种教材也已经很多了。另外，用于表现数据与流程的实体关系图(ERD)与数据流图(DFD)也会由于相同的原因而在某些地方使用到。

　　图4以图形方式显示了这三种应保留的模型的角色。简单地说，“架构”表现了系统结构，“领域模型”表现了问题领域中的关键概念，而“关键用例”则为系统的使用方式提供了示例。

图4，架构、领域模型以及关键用例

　　接下来我会以我的某个团队中所使用的真实示例与图片，分别解释这三个模型。

　　1. 架构的类图/包图

　　架构是对整个系统的一种结构化展示，它经常以类图或者包图的典型方式显现全局的层次(tier或layer)。举例来说，一个包含用户界面与数据库的应用程序，经常按照从用户界面到数据库进行水平分层，用例将跨越这些层以实现它的功能。

　　像“MVC”(模型-视图-控制器)这样的架构模式也可以作为一个全局架构。图5是某个架构的包图的示例，很显然它是基于某种MVC架构设计的。

　　团队中的每个人都应该理解架构中的各个部件的角色与作用，这样才能保证团队成员所编写的代码处于架构中的正确位置。

　　在这张图的多个包之间显式地表现了“依赖项”的存在，这样做是为了避免不必要的耦合或循环依赖。因为从架构的视角来说，内部包的循环依赖是糟糕的问题，它会提高测试的难度，并且增加编译的时间。

图5，架构的类图/包图(示例)

　　2. 领域模型的类图或实体关系图

　　领域模型描述了应用程序所在的领域中的概念分类。在人员交流的层面上，领域模型的词汇集将成为“Ubiquitous Language”，并且在全体项目相关人员之间使用，包括用户、领域专家、业务分析师、测试与开发者。

　　而在编码的层面上，领域模型对于为各种编程结构选择合适的命名也是非常重要的，包括类、数据、方法以及其它各种协定。概念分类(经常称为“实体”)中的很大一部分会被映射到数据库中的某个持久化数据结构，并且它们的生命周期往往会长于应用程序本身。通常来说，如果你的应用程序选择了某种“MVC”架构，那么你的领域模型(或者说实体)会驻留于你的逻辑架构中的“M”(模型)包内。而在Ruby on Rails类型的应用程序中，实体关系图将会更加适用于表达某个领域模型，因为模型与关系型数据库的关系更加直接与紧密了。