后果 使用这种架构很容易对两个层面的非功能性需求进行优化，但是你仍然需要小心不要将功能
需求重复实现。

现在，两个层面可能有完全不同的设计。比如，用户界面层可能使用配件模型（Widget Model），
以大量的视图来支撑，而领域层则基于分析模型。当布局设计发生变化时只会局部影响界面层，
但是性能需求的变化则集中在领域模型上。但是，又有新的地方需要注意：如果在两个层面冗余
地实现功能性需求的话，是有很大的风险的。例如，当一个对话框中没有符合业务规则的相关内容时，“OK”按钮要被禁止使用。我们会很希望将这个业务规则放在对话框类里面，令一方面，
在你的领域逻辑模型中也需要这样的标准（规则）。现在，当这个规则发生变化时，事情就乱套
了：你得在两个或更多地方进行修改。为了避免这些风险，域模型经常会提供这个领域的亚信息。
有效性方法（Availability Method）和领域层面类型（Domain Level Type）就处理这个问题。
层状设计让我们可以对它们分开考虑……但仍然需要一些预防措施，使得两个层面耦合，可
控。

经过这种模式的严格训练，你可以确保将表示部分和领域层面部分严格分离。当你为职责分
配（比如，应该放在界面部分呢，还是领域部分时）而举棋不定时，关键问题是：如果我将用户
界面换成批处理方式，这个功能还需要不需要？作为一个大致的规则，如果答案是“需要”，可
能将其放入领域层更合适一些；如果答案是“不需要”，你可能逮着了一个用户界面职责（功能）。
但是，在最后在两个层面间还有一个很广的接口。这些信息可以如下分类：

用户当前在使用的对象的只读上下文信息，
• 格式化规则，
• 关于某个特定动作能否在当前上下文中执行的信息，
• 领域层面的状态和进度信息，
• 触发行为（事务），以及
• 错误信息
领域层面存取（Domain Layer Access）讨论这些话题。

两个层面之间的实际信息流量依用户界面风格而定。假如你的用户界面是基于对话框的，有
一系列的表单，通常情况下就比“工具加材料”的模式上下文信息少一些。这就是为什么基于Web
的应用程序和大型机系统通常使用表单而好的基于PC 的系统则经常使用tool-material 隐喻的
深层次原因。

不是所有的现代开发环境都支持这种架构，假如支持的话，通常也需要更多的工作……然而，
这种层次架构仍然使得你能自由地对同一个系统进行不同的表示。

很多流行的框架（Framework）采用以用户界面为中心的方案。当用户点击了一个按钮，框
架就会调用相应的按钮对象的“点击”方法。至于在这个方法里面的动作则是程序员的事情。通
常情况下，是没有标准的过程甚至类来管理和领域层的通信的。所以，就需要通过训练来保证分
层－这不容易，特别是在进度安排紧张的情况下。但是，当你需要另外的表示时一个干净利落的
分层可以节省很多工作。你只需要将图形用户界面类替换为批处理方式类，或者一个CORBA 接口。

即使你不打算使用CORBA 接口，你也在分析操作时可以很快地给同一个领域层以不同的表示。例
如，很多界面支持通过剪贴板和拖放（Drag & Drop）来复制。两者都要求有不同的用户界面活
动和相同的领域层功能。

额外的层面可以使得用户界面适应一群用户的特别需求……但仍然不能把稻草变为黄金。
假如在领域层面使用了这个领域的元模型，顶层可以使用这些信息来组成一个界面，来组合
成一个用户的思维模型。例如，你可以表示域对象的硬编码属性，用同样的方法表示属性列表，
然后在用户面前隐藏这个属性列表。然而，领域层还必须支持转换。以一个面向事务系统的图形
界面化为反例：很多客户想，用一系列的HTML 表单来处理3270 个基于主机系统的表单，来形成
一个“现代的”用户界面已经足够。然而，一个成功的基于窗体的用户界面却来源于完全不同的
范式。现代界面不对业务过程建模，但提供一个工具集由用户自己来修改业务元素。显示在屏幕
上的大部分信息和用户在使用的特定业务过程没有关系――只是辅助用户的额外信息。从技术观
点来看，这意味着需要要比传统的系统提供更多的信息，在传统的系统里面用户知道其业务代码，
能正确地输入系统所需的数据。结果是这些系统的领域层被优化来处理事务，而不是提供所有的
额外信息。在最好的情况下，你会撞上性能问题，在最坏的情况下，你不得不重写整个系统。