基于表单的用户界面 在“基于表单的用户界面”里面，用户开始时选中某个业务处理（模块），然后应用程序就使用一系列的表单来引导用户完成整个处理过程。大型机系统上的大部分用户界面都是这样子的。[Cok97]中有更为详细的讨论。

面向对象系统 在这里指的是用面向对象技术设计和实现的应用程序。在本文里面，最重要的特征
是它们自己有一套对象，这一套对象有自己的生命周期，而且相互作用，从而完成应用
程序的功能。单个的用例或者事务不和架构相联系。

面向事务系统 在这种系统里，系统架构围绕事务进行，每一个事务都会调用一个不同的程序来操
作一个数据库。大部分使用事务处理器的程序，如CICS 等，都是用的这种方法。[GrR93]
中有详细的讨论。

本文阅读指引

在阅读模式语言的时候，一般不会走马灯似的看，都希望能仔细地阅读和研究。熟悉了本文的结构和布局，对文中的模式，你想深入到什么程度就深入到什么程度。想看看某个模式是说什么的，可以看看其概要。只要阅读了每个概要，你就可以很容易地了解整个语言的概况。如果你对某个模式的详细思想有兴趣，则可以阅读“上下文”部分，“问题”部分，和“解决方案”部分；如果你对这个模式的约束以及解决方案的取舍有兴趣，可以阅读相关的“约束”部分和“结果”部分。两部分都有主要说明，以标准字体出现，而小字体则用来讨论这些陈述。下图2 表示了建议的阅读途径。

 

图2

用户界面层（User Interface Layer）

概要 驱动一个用户界面总是通常比域复杂和容易变化……所以，把域层面从用户界面软件里分离
出来，将用户界面封装在一个独立的层面中。

上下文 当设计一个复杂商业系统的架构时，通常从一个大概的架构开始：如都有哪些主干等。在以前，技术因素是首要因素，最终会在内部结构大量地应用技术。那是一些系统有几种“标准架构”
的时代，是一个项目上有100 多人的时代。今天，很多架构师在开始对技术进行考虑之前，首先
使用域将系统分割成更小部分，称之为业务对象。

无论你走的是哪条路，迟早你都得考虑技术方面，将系统分的更细。其中一点就是如何将系
统展现在用户面前——这就是这个模式所探究的。它不单应用在面向对象系统里，还应用在面向
事务的设计，使用tool-material 隐喻的系统[Rie97]，以及基于表单的应用程序[CoK97]等等。
问题 该怎样将大型系统的用户界面溶入整个架构？

下面几件事情你得注意：

约束 用户界面表示了和你的需求模型一样的功能需求……但是，它还有不同的非功能性需求，这些需求导致很多用户不喜欢碍人的细节。

用户界面只是你的系统的一个界面，所以，它的内容是和你的需求分析模型中的需求分析是一
模一样的。一个初级方案是将所有的分析对象表示在用户界面上，将这些对象的方法作为界面上的
动作。不过，这办法好吗？一个好的分析模型的目标是减少冗余，是进行抽象化，以支持更好的灵
活性。在你对域对象进行设计时，要考虑这些：性能和耦合是主要的，还有并行性以及其它的避免
软件工程师厌烦的方面。但是，这些要考虑的东西，用户根本就不想介入。好的用户界面仔细地依
据用户在其领域的思维模型，尽可能地支持她的工作流程。当很多关于用户界面的改变需求来临时，一点也不用惊奇，这些改变对分析模型毫无影响。一群新的用户有不同的关于这个领域的思维模型，可能就需要一个新的用户界面，但哪怕是一丁点对象的改变都不用。因此，一个用户界面的非功能性需求和那些域对象是相差很大的。