如何组织应用程序的结构

发布网友发布时间：2022-05-04 17:39

共2个回答

懂视网时间：2022-05-04 22:00

从需求到形成有效的应用程序体系结构需要使用模型。建模是记录模型在应用程序域内的状态和行为的过程。需要考虑这些模式才能帮助解决设计问题。随着时间的增长，域内的模式会变成交流设计优缺点的一种语言。

在关于应用程序体系结构的本系列的第二部分（即本文）中，我们将了解与设计模式相关的技能、工具和里程碑，从而帮助您解决常见问题。设计工作至少有一部分需要考虑如何解决存在冲突的各个需求，这些需求通常表述为影响因素 (force)。模式标识适用的影响因素，并提供对这些影响因素进行调和的解决方案。

技能和能力

作为应用程序架构师，您应该能够辨认需求和系统设计中涉及的影响因素。您应该熟悉现有模式，并能够标识和记录新的域特定模式。最后，您应该能够应用（或创建机制来便于其他人应用）域或系统设计内有用的各种模式。

熟悉现有模式

尽可能熟悉现有模式。（请参见参考资料部分提供的指向模式语言和存储库的链接。）通过全面认识和了解现有模式，可快速地标识和创建模式。不过请注意，不要对所有设计问题都勉强套用现有模式。

标识模式

能够确定在需求集或系统设计中适用的模式，这是应用程序架构师的一项主要技能。虽然这样说，但我认为开发生命周期中不应该存在模式相关的阶段或活动。由于模式出现在各个抽象级别，且涉及多个开发活动，甚至可以应用于开发模型本身，这就使得在需要时以及针对危险执行应急措施时都自然而然地想到进行模式标识和应用，但您并不需要过于纠缠这方面的工作。

记录模式

我此处非常想讨论两个领域：模式内容的记录和模式用法的记录。您不仅应该能够创建易于理解的模式的影响因素、上下文和解决方案方面的描述，而且还应该记录模式在设计和实现中标识、应用或适用的位置。随着时间的增长，通过简单的收集和重构，就应该能够构建适用于应用程序域的涵盖范围更为广泛的模式语言。我并不是建议在工作中每次使用模式时都进行记录。我们习惯于遵循模式行事，这种自然的驱使力量无法抗拒。请仅记录有助于提高系统整体质量的重要设计方法。

当然，您应该熟悉一个或多个有关模式记录的行业方法和格式，而且需要熟悉特定于您的环境的任何标准。有关现有模式存储库和书籍的信息，请参见参考资料中提供的链接。

抽象

我在本系列的第 1 部分曾提到，抽象是需求分析的一项关键技能。勿庸置疑，这至少在有效使用设计模式方面也非常适用。当更改设计，以适应新需求时，请稍稍后退一步，抽象出细节，直到得到轴心点，在不影响现有元素的情况下可以在此轴心点处理特定类型的更改。这将很可能涉及到将现有模式作为候选解决方案来提供恰当的分离。

大部分模式都基于可插入性 (plugability)，也称为模板与挂钩 (template-and-hook)。将定义通用行为（模板），并提供域特定的行为和域类提供的状态（提供挂钩）。这是作为大部分模式基础的元模式，务必在开发自己的模式过程中记住这一点。

体系结构风格

体系结构风格 处理应用程序的全部或部分总体结构。特定的风格提供对应用程序的一个或多个质量属性的改进——通常以牺牲其他属性为代价。例如，管道和筛选风格允许在链的组件间实现方便的可组合性和松散偶合。不过，在此风格中的可分布性和可预测性会受到负面影响。您应该对其中的大部分结构设计原则加以熟悉——特别是您的应用程序域中应用的结构设计原则。另外，还要注意每个风格所具有的优缺点。

建模

正如我在本系列的第一篇文章中提到的，建模是应用程序架构师的一项关键技能。大部分与设计模式相关的操作都在建模领域中进行。甚至底层编码模式也可应用于此领域，因为可以将代码视为解决方案的另一个模型。您应该能够使用建模语言实现模式，以在其他项目中使用，而且应该能够将现有模式应用到模型。

为了将模式作为模型实现，需要使用建模语言创建属于模式的模板内容。对于统一建模语言（Unified Modeling Language，UML），这可以为单个包，其中包括相应的子包、类、关系和接口；或者可以为完整的建模项目，其中包含针对模式解决方案各个方面的多个模型。无论使用哪个工具进行建模，我都找到了创建这些模板的方法，以便重用整个体系结构模型或单个分析模式。

目前有多种将模式作为首要概念处理的多种建模工具可用。在这些环境中，可以为模型创建和应用模式，并能利用各个级别的自动化功能来支持将模式角色映射到模型对象。（有关更多信息，请参见工具和技术部分。）

要将模式应用到模型，涉及到将模式解决方案中的通用规则映射到模型中特定的域类。为此，您必须将模式需要的所有状态和关系添加到域类中。您还可能会希望更改模式的通用方面的名称，以与域的相应语言对应。例如，会计分析模式可能会包括 Account 和 Customer 之类的角色，而两个角色分别又涉及 getCustomer 和 getAccount 之类的操作。如果您的域包括希望对其应用模式角色的 CreditCard 和 Member，则可能会希望更改操作，以与之对应（即 getMember 和 getCreditCard）。您当然应该能够进行此映射工作。如果您的工具未实现此流程的自动化，请开发自己的脚本或宏。

回页首

工具和技术：分解应用程序

现代企业应用程序已变得相当复杂。应用程序体系结构中涉及的相互依赖组件的数量正在不断地增加。不过，我们仍然很少充分利用这种体系结构类型所带来的灵活性。让我们了解一下应用程序的实际情况以及企业应用程序的结构正如何发展为“分解”应用程序。

我将首先给出自己关于应用程序构成部分的简单定义。应用程序 是提供对计算资源的访问以支持特定用途的构造体。因此，大部分应用程序都包含以下组件：

规则——应用程序实现指定适用输入、输出可见性等的规则。

工作流——应用程序通过受支持的活动定义步骤序列。请注意，有些应用程序相对而言是“没有模式”，几乎不涉及工作流。另外，还可以利用上面提到的规则定义工作流。

子系统集成——应用程序可以与一个或多个子系统交互，在这些子系统之间提供受控集成。

事件——应用程序管理与外部及子系统间的事件流。此过程可以非常复杂（如异步事件队列），也可以非常简单（如重复调用子系统功能来调用行为、读取状态或传播状态的主循环）。

信息模型——应用程序在子系统的基础上定义其信息模型。信息模型是子系统状态和应用程序特定状态的组合视图。应用程序通常必须提供子系统间的一些信息映射。

绑定与传播——应用程序提供包括外部和动态配置、子系统状态视图和应用程序特定状态视图的信息模型。应用程序代码的大部分都涉及到在子系统间保持这些信息同步、响应更改以及将更改传播到相关组件。

所有这些导致了模式的出现：随着包括越来越多的支持应用程序功能的通用组件（例如，规则引擎、工作流引擎、企业服务总线），应用程序会变得越来越含混和分散，所包含的各个应用程序支持组件的声明规范和配置集合也变得越来越大。如果您是规模相当大的企业的架构师，请务必记住这一点。如果您所属的企业较小，也不要认为自己可以不受分解趋势的影响。您迟早（如果尚未开始的话）都会采用这种方式构建应用程序。

回页首

工具和技术：层次

到目前为止，我已经讨论了如何在多个抽象级别、应用程序整个周期甚至开发生命周期本身中标识、记录和应用模式。有了所有这些潜在的模式后，您需要采用某种方式对其进行组织。限制适用模式的一个方法是，根据其应用到的体系结构层次对模式进行分类。

图 1 中的关系图显示了不同类型的层次一种可能的安排方式。概念层次（业务、应用程序、信息和技术体系结构）显示在右侧。垂直部分是与应用程序及信息体系结构相关的逻辑层次。底部是技术层次，显示逻辑层次映射到物理基础设施的方式。这个安排显示了一个瘦客户机部署，其中的全部表示和一些应用程序逻辑都映射到了客户机物理层。

图 1. 层次映射

概念层次

概念层次 将非常抽象的模式空间划分为业务域模式、解决方案设计模式和基础设施模式。

逻辑层次

逻辑层次 根据层次的体系结构功能划分模式空间。可以采用多种方式定义逻辑层次，但通常分为三个或四个级别：

表示——支持信息显示和捕获外部事件及请求的组件。

应用程序——实现应用程序流、聚合信息和调用业务事务的组件。

业务——实现业务实体、规则、流程和事务的组件。

数据——提供对持久性数据和其他外部数据的访问的组件。

逻辑层作为应用程序部署体系结构的一部分射到物理层。这些映射也包含一些公用模式。例如，瘦客户机 或独立体系结构会将全部或大部分逻辑层映射到客户机物理层。分布式企业 Web 应用程序很可能会将逻辑层分布到一系列物理层。最后，富客户机 体系结构将表示层（还可以包括应用程序层）映射到客户机。

应用程序体系结构模式或原型涵盖所有逻辑层，定义完整应用程序的总体结构。其他模式将位于较低的粒度级别，作用于单个层次中的组件或组件交互设计。另一类模式涵盖两个层次间的交互。这种划分模式空间的方式至少能让您在寻找现有模式或对新模式进行分类时找到着手点。

物理层次

物理层次 根据模式应用的物理部署平台对模式空间进行划分。这个类别中的模式与解决特定平台上的问题相关。例如，您可以有一个通用会话状态管理模式以及多个平台特定的模式，用于在 Microsoft® ASP.NET 和 JavaServer Pages (JSP) 站点中实现通用模式。

J2EE

Java™ 2 Platform Enterprise Edition (J2EE) 标准将应用程序的逻辑层作为容器堆栈定义。所定义的容器有：

客户机容器——支持对应用程序资源的客户端访问。

Web 容器——处理客户机请求和用于进行显示的格式数据。

EJB 容器——为业务逻辑的高可用性、高性能实现提供环境。

连接器——提供对数据库和大型机等外部资源的访问。

回页首

工具和技术：组件设计模式

基于组件的软件工程（Component-based Software Engineering，CBSE）通过接口连接组件来构造系统的方式。重要模式包括契约式设计、定义良好的接口、可组合性、可预测的行为和组件测试。目前已经有很多关于组件的分布、交互和构造的模式和模式语言。我下面将给出一些例子：

交互模式——组件交互模式可帮助解决与体系结构的组件的协作、通信及协调相关的设计问题。与体系结构风格类似，这些模式处理应用程序体系结构的大型结构。例如，“抽象交互”(Abstract Interactions) 模式建议将组件交互作为抽象接口进行定义。通过与“组件总线” (Component Bus) 模式结合（以及精心的设计），可以创建没有耦合的灵活组件体系结构。

分布模式——组件分布模式处理与异类平台和环境中分布组件相关的问题和影响因素。

连接模式——组件连接模式处理组件如何“连接”到一起（动态或静态）。

行为模式——组件行为模式处理组件及其环境间的交互。

部署模式——部署模式帮助处理组件部署相关的影响因素。例如，在分布式组件体系结构中，组件间的延迟有时候会由于分布开销而不能接受。组件打包模式允许在灵活性和分布式环境的其他属性以及“本地”组件交互的可预测性能之间求得平衡。

业务组件工厂——业务组件工厂方法在 Peter Herzum 和 Oliver Sims 撰写的书中进行了详细说明（请参见参考资料）。此书给出了完整的模式框架，为企业的业务组件的规范、构造和部署工作提供支持。

依赖项注入—— 依赖项注入 是用于将对象或组件连接在一起的一项技术。依赖项注入不会构建对自身进行初始化的组件（包括创建依赖对象），而是将提供一个容器（或工厂），以查找或创建依赖对象和对所请求的对象调用 setter 挂钩来初始化其引用。通过此功能，可方便地重新配置组件，并能够方便地支持可插入设计，从而避免组件之间的硬编码依赖关系。这种类型的容器的一个很好的示例就是 Spring（请参见参考资料）——支持为传统 Java 对象（Plain Old Java Object，POJO）进行依赖项注入的开源容器。组件使用可扩展标记语言（Extensible Markup Language，XML）配置文件连接在一起。

回页首

工具和技术：企业集成模式

企业集成模式讨论企业内应用程序和系统的大规模集成。这些模式侧重于应用程序及其他信息系统组件间的通信。消息（以及消息的创建、路由、响应和转换）是这些模式中的主要概念。

回页首

工具和技术：企业应用程序模式

企业应用程序模式处理应用程序及其子系统的体系结构内的设计问题。这些模式讨论表示、到关系数据存储的映射、域逻辑、应用程序状态管理和创建的应用程序功能。

回页首

工具和技术：分析模式

分析模式处理业务域或解决方案域。这些模式解决在建模业务流程和实体过程中及业务事务的实现方法中的设计问题。

回页首

工具和技术：原型 (Archetype)

原型是在某个域或多个域中重复出现的通用概念和模式。可以将其映射到特定的域，并能用于进行模型转换、代码生成等工作。Party、Inventory、Purchase Order 和 Money 就是这方面的例子。虽然和分析模式类似，但原型的抽象级别更高。原型可以包括可选功能、选择功能或基于业务上下文的完整结构变体（异形结构）。

回页首

工具和技术：表示模式

表示模式处理信息的显示及处理操作信息或调用应用程序流的事件。此领域的模式的主要目标是将表示特定的方面从应用程序及业务逻辑分离出来。其中的一些例子包括：

模型-视图-控制器（Model-View-Controller，MVC）——此模式将应用程序模型的可视表示形式（视图）从模型本身分离。控制器负责更新视图和调度视图级别的事件。

表示-抽象-控制（Presentation-Abstraction-Control，PAC）——此模式在很多方面与 MVC 相似，也将功能分离为类似的角色。PAC 比 MVC 更为抽象和通用，可能更适合在用户界面（User Interface，UI）之外的领域使用。从某些方面而言，此模式与层次相关，因为可以使用类似的模式来设计每个层次边界的交互。一个层次的模型就是另一个层次的视图。通过将此模式作为组织体系结构原则使用，可为“可插入”体系结构提供极大的支持。

前端控制器 (Front controller)——前端控制器适用于请求/响应类型的交互，将使用单个对象来接收请求、进行调度、路由并收集响应。

显示服务器——此模式将表示实现定义为显示信息和订阅事件的抽象服务。此模式最成功的用法是 X Windows 系统。

回页首

工具和技术：面向服务的体系结构

从很多角度而言，面向服务的体系结构（Service-Oriented Architecture，SOA）是对基于一组常见影响因素（与以组件为基础的应用程序相关）的模式集的标准化。组件充当服务实现，而服务相关的基础设施处理关于连接、交互等等的决策，如上面的工具和技术：组件设计模式中所述。

服务组件体系结构

服务组件体系结构（Service Component Architecture，SCA）是定义了一种声明语言（基于 XML）的 IBM 项目，可将此语言用于指定组件的组装以及其内部和外部服务接口依赖关系。可以采用 Spring 的方式将组件连接到一起，但 SCA 将组件连接功能安排到了实现模块的分布边界之外。此标准现在由 Open Service-Oriented Architecture Collaboration 进行管理。

模型驱动的体系结构

模型驱动的体系结构（Model-Driven Architecture，MDA）中支持模型转换和充实的功能也可以支持基于模式的就地模型转换。IBM® Rational® Software Modeler 和 Rational Software Architect 提供了定义模式并将其直接应用于模型的支持。ArcStyler（iO Software 的产品）为 MDA 提供了成熟而广泛的支持，可以用于应用模式转换。

回页首

里程碑

架构师的工作中总会涉及到模式的标识和应用。由于这个原因，很难在项目周期中确定特定的点来说明模式工作的进展。不过，我希望在此讨论应用程序生命周期中一些重要的部分，应该在这些方面寻找和确定应用程序中的模式。

体系结构

应用程序体系结构是主要的交付内容，而在大多数情况下，模式在其开发中扮演着极为重要的角色。标识体系结构风格及在体系结构中使用的其他大型模式具有多方面的作用。模式可以带来以下好处：

使体系结构更易于理解和说明。

通过所使用的模式的已知特征重点突出主要体系结构决策和优缺点。

允许重用模型和事项的较大组成部分，特别组织依赖于最佳实践模式作为框架和工具时更是如此。

域模型

域建模并非真的很新，但关于如何进行相关工作的信息却比较少。Eric Evans 撰写的书 Domain-Driven Design（请参见参考资料）提供了一组用于建模域的模式，其中包括用于标识及确定域边界和细化域设计的技术。

通过使用这些技术来记录域，将极大地提高应用程序体系结构的有效性和持久适用性。

分析模型

大部分域通常都得到了大家的认可和实现了自动化。因此，域模型能够充分地利用设计良好模式语言。请寻找为您的域提供全部或部分支持的可用模式。如果没有此类模式，请考虑自行创建一个。这些模式应该为在域或标准模式中经常重复出现的模式（如 money 和 currency 模式）。

设计和实现

同样，在应用程序生命周期的设计和实现阶段有很多方法和时机使用模式，很难指定与模式相关的特定交付内容。不过，基于模式和抽象的恰当使用的体系结构将更易于理解和维护。您应该能够演示在何种情况下使用模式（在特定区域内使用或作为体系结构指导原则使用）处理了某个需求或提高了体系结构的总体质量。

方法

在我看来，建议的开发方法属于应用程序体系结构的一部分。在网络和一些文献资料中提供了很多开发模式。其中一些重要的例子有：

统一流程 (Unified process)——一种迭代式的分阶段开发方法，在 IBM Rational 和 IBM Rational Unified Process® (RUP®) 的推动下得到了广泛的应用。RUP 包括可以用于配置基本统一流程框架的工作流和模版。

RM-ODP——开放式分布处理的参考模型（Reference Model for Open Distributed Processing，RM-ODP）是系统体系结构规范的建模方法。RM-ODP 将系统的规范和建模拆分为视角，其中每个视角处理一组特定的考虑事项。

极限编程（Extreme Programming，XP）——XP 是轻量级方法，避免了与“测试第一”方法相关的正式建模和分析。系统需求作为用户案例捕获。用户案例转换为相应功能的测试，然后编写代码实现测试用例。此模式最适合用于小型的技能娴熟的团队，难以扩展为大型项目。

Scrum：另一个轻量级方法，侧重于短期的成就（团队针对其提交特定的交付内容）。会频繁评估进度并根据风险和需求优先级的要求调整工作投入。

回页首

总结

处理模式是架构师日常工作中所必须涉及的内容。正如我在第 1 部分提到的，抽象和建模是两项关键技能。二者都与模式有关系。您必须能够将相关抽象从具体需求中提取出来，从而不仅形成体系结构的总体概貌及其指导原则，还能处理关键设计问题，或在设计和实现的较低级别对风险带来的更改做好准备。

另外，并非所有内容都是模式，也不是每个模式都值得记录和发布。应用不恰当或不必要的模式可能会莫明其妙地让您的设计变得复杂。请始终记住每个模式的优缺点，并对影响其使用的实际影响因素进行评估。

热心网友时间：2022-05-04 19:08

适用于应用程序使用的软件设计和构架总结软件架构一般定义为应用程序的结构。在定义这些结构的时候，软件架构师的目标就是使用不同级别的抽象，通过根据关注点把功能进行分割来最小化复杂度。我们会从最高层的抽象以及不同的关注点开始研究。因为设计的过程中需要不断深入这些层次、扩展关注点直到定义了结构为止。内容目标概览概要步骤第一步——选择我们的分层策略第二步——定义层之间的接口第三步——选择我们的部署策略第四步——选择通讯协议其它资源目标找出并选择分层策略定义层之间的接口找出并选择部署策略选择合适的通讯协议概览在开始应用程序设计的时候，我们第一个任务就是关注最高层次的抽象并且开始把功能分组到不同的层中。然后，我们需要根据我们所设计的应用程序的类型为每一层定义公共的接口。在定义了层和接口之后我们就需要决定应用程序是如何部署的。最后，最后一个步骤包含选择会用于在应用程序不同逻辑层和物理层之间通讯的协议。概要步骤第一步——选择我们的分层策略第二步——定义层之间的接口第三步——选择我们的部署策略第四步——选择通讯协议第一步——选择我们的分层策略层表示组件按照不同关注点的逻辑分组。例如，业务逻辑表示应该分组到某层的一个关注点。这可能是应用程序最初设计中最重要的一个抉择。然而，有很多种方式可以把功能进行分层。在完成了本步骤之后你应该能理解如何来组织应用程序的分层结构。下图演示了用于大多数业务应用程序设计的主要层。在这个示例中，功能按照表现逻辑、服务逻辑、业务逻辑和数据访问逻辑进行分组。如果服务没有公开的话，就不需要服务层，那么我们应该只有表现、业务和数据访问层。这只是一个示例，不是对应用程序进行分层的唯一方式。然而，一般来说分层在软件设计中很常见。底层的操作系统设计使用了RING的方式，RING0（内核）表示最低的层，它可以直接访问诸如CPU和内存等硬件资源。设备驱动作为外层RING通过RING0提供的接口和硬件进行交互。应用程序代码包含在最外部的RING中，它们通过设备驱动来和硬件交互。除了层，我们还有一些功能会跨越层，它们通常称作横切。此类功能包含诸如日志以及异常管理等。有不同的方式来处理这种功能，比如公共类库、使用元数据直接在编译输出中插入横切代码的面向方面编程（AOP）等。在为应用程序选择分层策略的时候，如下事项是我们需要考虑的关键点：决定我们是否需要层选择我们需要的层决定我们是否需要合并层决定层之间交互的规则决定我们是否需要层在大多数情况下总是需要把功能进行分层。然而，在有些特例下不需要。例如，如果我们构建一个非常小的应用程序，可能就会考虑在用户界面事件处理程序中实现表现、业务逻辑以及数据访问功能。此外，一些软件工程师会认为跨层边界或增加层带来的开销会对性能有负面影响。是否使用分层的决定说白了就是性能对可维护性。虽然不使用分层可以提升性能，因为所有的东西都紧密耦合在了一起。但是，这种耦合会严重影响应用程序的扩展和维护能力。说实话，对可扩展性和可维护性的影响远比获得的那一点性能的提升重大。不管怎么始终应该考虑分层，我们的目标其实是决定应用程序需要怎么样合适的分层。选择我们需要的层有几种不同的方式来把功能进行分层。例如一种分层的方式就是表现、服务和数据访问。许多关注业务领域的面向对象设计使用又一种不同的分层策略，最底层用于基础结构代码，提供类似数据访问的支持。上面一层就是领域层，用于包含业务领域对象，最顶层包含应用程序代码。对于使用微软.NET Framework开发的大多数业务应用程序来说，按照表现、服务、业务以及数据访问对功能进行分组是不错的选择。下面描述了每一层中的一些组件，以及什么时候不需要这层。表现-这层包含用于处理用户接口请求以及呈现用户接口输出的组件。如果我们的应用程序没有用户接口的话就不需要表现层。服务-这层包含用于处理服务请求的组件。例如，对于使用Windows Communication Foundation (WCF)的应用程序，我们就会找到定义契约的组件、用于实现接口以及提供在实现类和外部契约类之间提供转换支持的组件。如果我们的应用程序不提供服务，则不需要在设计中包含服务层。Business业务-这层包含用于处理表现或服务层请求的组件。在这层中的组件包括业务处理、业务实体以及业务工作流。在一些情况下，我们不需要有任何的业务层并且只需要从数据源获取数据，也就是说这种情况下不需要业务层。数据访问-这层包含用于管理和数据源交互的组件。例如，使用ADO.NET的话在数据访问层中就会有连接和命令组件。如果我们的应用程序不使用外部数据的话那么我们就不需要实现数据访问层。决定我们是否需要合并层例如，应用程序具有很有限的业务规则并且主要关注验证的话可以在一层中实现业务和表现逻辑。在以下情况考虑合并层：如果我们的业务规则很有限，在一层中实现业务和表现逻辑是合理的。如果我们的应用程序从服务获取数据并且显示数据，可以直接为表现层添加服务引用并且直接使用服务数据。这样的话就可以合并数据访问和表现。如果数据访问服务直接访问数据库中的表或视图的话可以考虑在服务层中实现数据访问功能。还有一些适用于合并分层的示例。然而，基本准则是我们总是应该把功能分层。在一些情况下，层只不过是一层调用并且没有提供什么功能。然而，如果把功能进行分离的话我们就可以在影响很小或没有影响的情况下扩展其功能。决定层之间的交互规则分层策略带来的一个问题是我们需要定义层之间如何交互的规则。指定这样的一种交互规则的主要原因是最小化依赖以及消除循环引用。例如，如果两个层依赖另外那个层的组件就很可能带来循环依赖。最常见的准则是只允许层之间的单向交互。从上到下的交互–比较高的层可以和其下层进行交互，但是低层不可以和其上的层进行交互。在设计中总是应该强制这样的准则来避免层之间的循环依赖。紧密交互 –每一层只能直接和其下的层进行交互。这个准则可以强制严格的关注分离，应该每一层只知道其直接下属层。这个准则的好处是对某一层的修改只会影响其直接上层。松散交互–高层可以跳过一些层直接和底层进行交互。这可以增加性能，但是也会增加依赖。换句话说，对底层的修改可能会影响其上的多个层。考虑使用紧密交互规则：如果我们设计的应用程序会不断修改来增加新的功能，并且我们希望最小化改变的影响。如果我们设计的应用程序可能会跨物理层进行分布。考虑使用松散交互规则：如果我们设计的应用程序肯定不会跨物理层进行分布。例如是安装在客户机上的独立富客户端应用程序。如果我们设计一个很小的应用程序，影响多层的改动工作量不大。检查点在结束本步骤之前，你应该可以回答如下问题：你是否找到了应用程序需要的功能并且把功能分层？你是否定义了层之间如何交互的规则？第二步——定义层之间的接口对于为层定义接口，最主要的原则是在层之间使用松散耦合。意思就是层不应该公开内部组件让其它层来依赖。而是，层的接口应该设计为最小的依赖性，提供公共接口并且隐藏层中组件的细节。隐藏细节叫做抽象，有很多种方式实现抽象。如下设计方式用来为层定义接口：抽象接口 –可以通过定义抽象基类或类型定义来实现。基类或类型定义了所有层消费者用于和层进行交互的公共接口。通过使用实现抽象接口的测试对象，有的时候又叫做mock对象，可以增进可测试性。公共设计类型 –许多设计模式定义表示不同层中接口的对象类型。这些对象类型提供了一个抽象，它隐藏了层中的细节。例如，表数据入口模式定义了表示数据库中表的对象类型。这些对象负责实现和数据库交互的必要SQL代码。对象的消费者不需要知道使用的SQL甚至不需要知道连接数据库和执行命令的细节。依赖倒置 –这是一种编程模式，抽象接口定义在任何层的外部或不依赖于任何层。层不依赖于公共接口，而不是一个层依赖于另一个层。依赖注入模式是依赖导致的常见实现方式。通过依赖注入组件，一层可以通过使用公共抽象接口来注入到其它层的组件中。基于消息 –基于消息的接口可以用于提供层之间的交互，而不是直接和组件进行交互。有多种消息解决方案，比如web服务和支持跨机器和进程边界的微软消息队列。然而，你也可以组合抽象接口和用于定义要交互的数据结构的公共消息类型。基于消息最主要的区别是层之间的交互使用公共结构，它封装了交互的细节。这个结构可以定义操作、数据架构、错误契约、安全信息以及其它和层之间通讯相关的细节。考虑使用抽象接口：如果你希望使用接口具体实例来实现不同行为的能力。如果你希望使用mock对象来增加应用程序的可测试性。考虑使用公共设计类型：如果你在为层中的接口实现设计模式。许多设计模式基于抽象接口，然而，一些基于具体类。如果你希望一种快捷而简单的方式实现层接口。比如表数据入口模式。考虑使用依赖导致：如果你希望提供最大的可测试性，这个方式允许你诸如具体的测试类到设计中的不用层中。考虑使用基于消息的：如果你要实现一个web应用程序并且在表现层和业务层中定义接口。如果你有一个应用程序层需要支持多个客户端类型。如果你希望提供跨物理和进程边界交互。如果你希望以公共接口进行交互。如果你要和一个无状态的接口进行交互，状态信息使用消息进行携带。对于web应用程序表现层和业务逻辑层之间的交互推荐使用基于消息的接口。一般通过使用Windows Communication Foundation (WCF)或提供公共消息类型的抽象接口来实现。在表现层和业务层之间使用基于消息的接口的原因是因为web应用程序的业务层不维护调用间的状态。换句话说，每一次表现层和业务层中的调用都代表一个新的上下文。通过使用基于消息的接口我们可以随请求传递上下文信息并且为表现层中的异常和错误处理提供一种公共的模型。检查点在结束本步骤之前，你应该可以回答如下问题：你是否需要使用抽象接口提供测试性？你的接口是否需要提供跨进程和机器边界交互？你的业务层是否需要支持多个客户端类型？你是否会使用基于消息的接口在web应用程序的表现层和业务层之间进行交互？第三步——选择部署策略对于大多数解决方案中都可以找到几种常见的模式，它们表示了应用程序的部署结构。如果要为我们的应用程序决定最佳部署解决方案，首先需要了解常见的模式。在理解了不同的模式之后，然后你就可以考虑场景、需求以及安全约束来选择某一种或多种模式。客户端-服务器这个模式表示具有两个主要组件：客户端和服务器的基本结构。对于这种情况，客户端和服务器可以在相同机器上也可以跨越两个机器。如下示例演示了常见的web应用程序场景，客户端和web服务器进行交互。N层这个模式表示应用程序组件跨域一个或多个服务器的结构。下图表示了2层部署，所有应用程序代码位于客户端而数据库位于分离的服务器中。3层在3层设计中，客户端和部署在独立服务器的应用程序软件进行交互，和数据库进行交互的应用程序服务器也是单独的服务器。这是许多web应用程序和web服务常见的模式。 4层对于这种情况，web服务器从物理上和应用服务器分离。这么做通常处于安全的目的，web服务器部署在隔离区域（DMZ）中而应用程序服务器位于不同的子网。我们一般会在客户端和web层以及web层和应用层或业务逻辑层之间假设2道防火墙。考虑客户端服务器或2层：如果我们在开发一个需要访问应用服务器的客户端。如果我们在开发一个访问外部数据库的独立客户端。考虑3层：如果我们在开发基于局域网的应用程序，所有服务器都在一个私有网络中。如果我们在开发基于Internet的应用程序，并且安全需求不约束在公共的web/应用服务器中实现业务逻辑。考虑4层：如果安全需求规定业务逻辑不能在DMZ中部署业务逻辑。如果我们的应用程序使用服务器上的资源很厉害并且我们希望把功能分离到另一个服务器。在大多数情况下推荐让所有的应用程序代码放在相同服务器。任何需要跨物理边界的需求都会影响性能因为数据需要在这些边界进行序列化。然而，有一些情况下我们需要跨服务器分离功能。此外，根据服务器的位置我们可以选择性能最优化的通讯协议。检查点在结束本步骤之前，你应该可以回答如下问题：安全需求是否规定业务逻辑不能部署在公开的DMZ中？我们是否在开发独立的只需要访问数据库的客户端？我们是否在开发web应用程序或web服务？我们是否在开发有多个客户端的应用程序？第四步——选择通讯协议说到设计中用于跨逻辑层或物理层进行通讯的物理协议，通讯协议的选择对我们应用程序的性能起巨大作用。选择通讯协议的一个主要的地方就是使用服务和数据库进行交互。 Windows Communication Foundation (WCF) –直接支持四种协议： HTTP –用于在Internet上公开的服务。 TCP –用于在网络内部署的服务。 NamedPipes –用于服务和其使用者部署在同一服务器的服务。 MessageQueue –用于通过微软消息队列实现进行访问的服务。 Database –支持和WCF一样的许多协议。 HTTP –用于在Internet上公开的数据库。 TCP –用于在网络内部署的数据库。