5.3自由度的约束

5.3 自由度的约束

价值增加的方式要求有一个显式的架构，但是架构也可以从实现中产生。这表面上是矛盾的。一方面，你必须在应用场景的情景环境下考虑所有的服务质量和部署约束。另一方面，价值增加的思维方式认为已测试的可运行代码才是对系统进展的最好度量，并且开发行为就是设计行为，虽然这是在非常明细的级别上。在需求范围固定的小型迭代中，正是开发的行为使得设计可以从实现中产生。

答案在于项目生命周期的早期对基线架构的创建过程中。

5.3.1基线架构

基线架构是一个可执行的框架式的应用，它是特意为减轻技术风险和为项目迭代提供一个牢固稳定的基础而设计的。一些敏捷开发者将其称为“0迭代”，这时已经安装了平台基础设施构件，并且构建好了一个系统的“垂直薄切片”，从头到尾地（例如，从用户界面到数据库）检查了一个非常简单的应用场景。这里的目的是无二义性地清洗和验证项目的架构  方面的重要机制。去除二义性要求基线架构是可执行的。

作为一个例子，考虑一下一个流行的应用风格——使用关系数据库的Web应用。在早期，需要回答一些关于“什么是最适合的”的基本问题，回答这些问题时，要基于好公民的理念和各代言组（在第2章中描述过）的所有观点。

个应用系统是应该采购还是应该开发？这个应用系统应该是一个智能客户端系统还是一个Web系统？如果它是一个Web应用，哪些处理应该在客户端使用AJAX之类的技术来完成，哪些处理应该在服务器端完成？对于持久性（假设是关系数据库），选择关系数据库的组织级标准是什么？是应该新建一个数据库实例呢，还是在已有的数据库实例中增加表？此应用所涉及的数据的来源是什么？此应用应该怎样与企业中的其他应用相集成？此系统每天必须能够执行多少业务交易才能支持该项目的经济合理性论证（economic justification）？这个应用在集团数据中心里部署、运行和维护吗？如果是的话，该数据中心的技术约束是什么？一旦在项目生命周期的早期做出了这些基本的决策，它们所导致的约束将指引所开发的项目并能使该项目稳定。

需要追求一种精妙的平衡。一旦你解决完这些技术问题，应努力将决策推迟到“最后的责任时刻”（last responsible moment）。然而，“最后的责任时刻”会因项目的复杂度不同而不同。在项目生命周期的早期，将第2章中所说的代言组都聚在一起，目的就是对高层次的决策政策达成一致意见。通常，你会让接口和方法重构之类的详细设计问题随着实现而演化。在那些有很多依赖的更复杂的项目中，你可能需要在早期就确定好接口并减轻架构上的重大风险，从而避免后面的返工。然后，在一致同意的政策下，构建一个实现了这些概要设计决策的可执行的基线，这样这些决策就可以成为这个项目的架构约束。

在早期定义这一基线，为应用开发提供稳定的平台基础设施构件和协议，这对开发人员很有好处。在早期定义这些约束，还能让其他涉众具有预言能力并能进行计划。例如，发布/操作代言组可以为部署和管理生产环境的应用进行计划，也可以确保数据中心的就绪。业务线中的产品管理代言组能够创建市场计划，以此来设计在系统能够支持的交易率水平上使用的吸引力等级。业务分析员可以设计业务过程的监控报告，以此来分析应用系统的投资回报，这将反馈到下一个版本的计划中。企业架构师能够设计并实现跨企业的可复用服务，向着企业级SOA移植。早期定义这些约束使多个涉众都能够有一个稳定的、可预见的基础。

5.3.2验证架构决策

这一过程不仅仅是自顶向下的。你需要通过构建一个可执行的框架式架构来自底向上地验证这些约束。VSTS让你能够使用逻辑数据中心设计器(Logical Datacenter Designer，参见图5-5)来对原有的数据中心建模，使用系统和应用设计器（System and Application Designer，如图5-3和图5-4所示）来为所要开发的应用系统建模，然后运行验证报告来确定二者之间的冲突。这样，系统和应用模型就可以用来生成框架代码了，这些框架代码可以成为可执行基线的一部分。

这样做能够带来很多好处。运行代码是没有二义性的——设计的区域应当看起来是不清楚的，源代码则是可以参考的。运行代码可以用于性能测试，从而验证系统的最初交易率。系统设置可以与数据中心政策相校验，从而识别出潜在的冲突。构建一个可执行系统还迫使更低层的设计的决策变成显式的，并对基线进一步精细化。

5.3.3精细化基线

一旦构建出能从头到尾运行的框架式架构，你就会被迫考虑更低层设计的决策。你的应用逻辑的结构如何？你的数据访问方式是什么？你是要把业务逻辑部署在与Web服务器相同的服务器上，还是部署在单独的应用服务器上？要使用什么认证和授权机制？在服务器之间要使用什么协议？

不要试图解决所有的关注点。选择那些技术风险最高的区域来验证，让其他决策从实现中产生。考虑构建一个最简单的框架式应用，以它来满足你的约束、减轻技术风险，并为开发的迭代提供一个充分的、稳定的基础。

精细化基线的详细例子

对于此技术的详细例子请参见MSDN Tech Note:

TN_1111: Top?Down System Design

http://msdn.microsoft.com/vstudio/teamsystem/reference/technotes/system_designer/topdown_sys.aspx

你还应既借助设计知识，并借助之前解决过类似问题的其他人的经验，以及在模式中学到的知识。模式还给了你一门语言，运用这门语言可以简明地描述解决方案，通过复用已知的好设计来减轻风险，让你的工作在将来可以得到维护和复用。

.NET 框架专用的模式

对于.NET框架专用的模式，请参见http://msdn.microsoft.com/practices。

5.3.4参考架构

在很多情况下，你可以使用参考架构作为基线。例如，微软创建了一个参考应用叫作实用集成基线(Applied Integration Baseline，AIB)，它使用基于模式的方法来构建可执行基线（参见图5-2）。此应用带了超过12个Visual Studio工程，它基于ASP.NET、BizTalk Server、SQL Server、Host Integration Server和VSTS。

 



图5-2 应用集成基线提供了一个交互式的“讲述者”，用于形象化基线架构。这一可视化模型包括了VSTS应用设计器和逻辑数据中心设计器模块，还有对系统的基于模式的描述。这里讲述者通过在应用设计器图上画出每一步来一次一步地演示应用场景

Windows Server System参考架构

对于计划基础设施和数据中心，你可以从http://www.microsoft.com/technet/itsolutions/wssra

/raguide/default.mspx下载Windows Server System参考架构。

类似地，Windows Server System参考架构(WSSRA)为基础设施架构提供了一个用于数据中心配置的基线。显然，实际环境会有所不同，但是WSSRA基线提供了一个设置服务器环境的首选模型。

下载应用集成基线

你可以从MSDN库下载应用集成基线，其主题为：

MSDN Library

Servers and Enterprise Development

Enterprise Architecture, Patterns, and Practices

Microsoft Patterns & Practices

Reference Implementations