逻辑架构的精化
目标：
- 进一步研究逻辑架构种的问题和层模式，包括层之间的协作。
- 展示案例研究在本次迭代的逻辑架构。
- 在分层架构的语境中应用外观、观察者和控制器模式。
示例：NextGen的逻辑架构
层之间和包之间的耦合
层之间和包之间的交互场景
使用层模式的协作
架构曾是上有两个重要的涉及决策：
- 哟u那些大尺度分块
- 它们时如何连接的
架构性的层模式用来指导定义大尺度的分块，同时诸如外观、控制器和观察者这样的围观架构涉及模式则用例涉及层和包之间的连接。
简单包与子系统
某些包和层不仅仅时概念上的一组事物，事实上它们时具有行为和接口的子系统。
在UML种，子系统可以用构造性来标识。
外观
对于表示子系统的包，GoF外观模式是最常用的访问模式。一个公共的外观对象定义了子系统的服务，客户端不与子系统内部的构件交互，二十通过与外观对象协作来访问子系统。
外观不应该暴露太多底层操作，相反，它只应该保留少数高层操作。当外观暴露过多底层操作时，内举行可能会变差。此外，如果外观将作为或可能称为分布式或原创对象，则细粒度的服务将导致原创通信的性能问题：大量的小型远程调用时分布式系统的性能瓶颈。
通常，外观不会直接执行任务，二十由因此在外观下的子系统对象来完成工作，外观时这些对象的统一或中介。
如果应用只有少量系统操作，则应用层或李宇春通常只像桑一次暴露一个对象。另一方面，技术服务层包含了几个子系统，每个子系统至少要向上一层暴露一个外观。
会话外观和应用层
当应用具有许多系统操作，并且支持许多用例时，则通常在UI和领域层之间采用多个对象作为中介。
当系统不断增长，需要处理许多用例和系统操作时，则通常会引入应用层的对象来维护用例操作的会话状态，每个会话示例标识与一个客户的恢复，这被称为会话外观，它同时也是GRASP控制器模式所推荐的另一种用法。
控制器
GRASP控制器模式描述了在UI层发起系统操作请求时客户端处理器的常见选择。
系统操作和层
SSD种图解了系统操作，图中隐藏了UI对象。
与观察者的向上协作
外观模式通常用于高层到底层的向下协作，或者访问同一层其他子系统的服务。当处于较低处的应用或者领域从需要向上与UI层通信时，通常使用观察者模式。
松散分层耦合关系
在大部分分层架构种，层之间的耦合并发与基于OSI7层模型的网络协议一样具有限制。在协议模型种具有严格限制，第N层的元素只能访问相邻的第N-1层所提供的服务。
在信息系统架构种很少严格遵循上述限制。相反，这里的标准时“松散讽刺”或“透明分层”架构，在这种架构章，某一次的元素可以与其他肉干脆进行协作或耦合。
油罐车之间的典型耦合由下面的注解：
- 所有高层都依赖于技术服务层或基础层。
- 领域从依赖于业务基础设施层。
- UI层调用应用层的服务，应用层又调用领域从的服务。出发没有应用层，否则UI层不直接调用领域层的服务。
- 对于但经常的“桌面”应用，领域从的软件对象对于UI层、应用层可见，或者在上述各层之间传递。
- 另一方面，在分布式系统种，通常将领域从对象的许力和副本或数据只有这传递给UI层
与技术服务层和基础层之间的耦合危险吗
如同前面对GRASP防止变异和低耦合的讨论，问题的关键不是耦合本身，二十对不稳定的变化点和进化点的不惜要耦合。没有必要花费时间和金钱去抽象或者隐藏某些不会改变的事物。类库时相对稳定的，因此对类库的高耦合关系不会造成问题。
有关层模式的其他问题
除了上面以及讨论的结构和协作问题，有关层模式还有下面一些问题值得讨论。
架构的逻辑、进程和部署视图
架构的分层结构时它的漏极视图，而不是元素到进程或处理节点的部署视图。根据不同的平台，所有曾可以部署在统一个处理解决的同一个进程种，也可以如同大规模web应用一样，跨越多态计算机和多个进程。
UP种的部署模型将这种逻辑架构映射到进程和节点，并且很受软件和硬件平台以及相关应用框架选择的影响。
有都铎未部署而切分楼及层次结构的方法。虽然部署架构的主题并非不重要，但是由于它依赖于所选择的软件平台细节，而且远远超出了本书的范围，因此这里只进行了简单的介绍。
应用层时可选的吗
如果存在应用层，则其作为UI层和领域从之间的中介，容量复杂获知客户会话状态的对象，并且复杂控制工作的流程。
在某些应用程序种，并不需要应用层，当下述情形发生时，应用层居于效用：
- 系统使用多个用户接口。应用层的对象可以充当复杂手机和合并不同用户接口数据的适配器，同时中档英寸对林古城访问的外观。
- 在分布式系统种，领域从与UI层部署在不同的节点，有多个客户但访问。在此情形下，通常需要追踪会话状态，应用层的对象可以用来承担此职责。
- 领域从不能或不应该维护会话状态。
- 通过限定窗口或Web页面的顺序定义了工作流，并且必须时表示这一工作流。
不同层的模糊集合成员
某些元素很明确第归属于某层。但是，特别是对于技术负责和基础层，或领域从或业务及尺寸，很难区分某些元素在期间的归属，因为这些层之间的差异玩玩粗略第用高、第或特殊与一般来亨利，而这些都是模糊集合的术语，这是经常发生的事情，而实际上也无需精确分类，开发团队可以粗略第将技术服务层和基础岑更堪称一组，成为基础设施层。
层的障碍和禁忌
- 在某些情形，增加层将导致性能问题。
- 层模式时少数几个核心架构模式之一，但并不是对所有问题都使用。
已知的应用
大量现代面向对象系统的开发都采用了层：你很难找到不遮掩做的例子。
虚拟机和操作系统
信息系统：经典的三层架构。
在20世纪70年代，对信息系统分层架构的早期描述种包括了用户接口和持久性数据存储，这一架构被称为三层架构。
对三层架构的经典描述如下：
- 接口
- 应用漏极
- 存储。
三层架构的突出特点时将应用逻辑分成不同的软件逻辑中间层。窗口或Web页面将任务请求传递给中间层，中间层与后台的存储层通信。
两层涉及具有快速初始开发的优点，但也存在问题。尽管如此，对于主要时简单CRUD操作的数据密集型系统，两层涉及是一个合适的选择。
相关模式
- 间接性：层可以未底层服务增加一层间接性
- 防止变异：层可以防止实现种的变化所产生的影响。
- 低耦合和高内聚：层强烈支持这些目标。
- 其特定于面向对象信息系统的应用参与。
其他名称
层模式也被称为分层架构。
模型-视图分离和“向上”通信
窗口如何得到需要现实的信息？通常能够满足需要的方法是，窗口向两样东西发送消息，查询其将要在窗口小部件种现实的信息--刷新现实的轮询或从上面啦的模型。
但是，有时候轮询模型也有不足。例如每秒钟从上千个对象种找出几个变化了的对象，并用来刷新GUI现实，这是毫无效率的。在这种情形下，更为有效的方法是，在领域对象状态发生变化时，由少数变化了的领域对象向窗口通信，一次引起现实的刷新。
在这些情形下，需要从下面退模型进行现实刷新。由于模型-视图分离模式的约束，这就需要从底层对象向上到窗口之间实现“间接性”通信，由下向上推出刷新的通知。
有两种常见解决方案：
- 观察者模式，使GUI对象简单第作为实现了诸如PropertyListener这样的接口的对象。
- UI外观对象。也就是在UI层增加接受来自底层请求的外观。