部分和章节 本书大致从构架商业周期的角度，分为4部分讲述了构架如何适合企业的需要。
- 预想构架：第1~3章
- 创建构架：第4~10章
- 分析构架：第11~13章
- 从一个系统刀多个系统：第14~19章
第3，6，8，13，15，16和17章提供了案例分析，在各章的标题中已明确标出。
第一章 构架商业周期
-
系统的构架视图是抽象的，它不考虑实现、算法和数据表示的细节，集中研究“黑盒”元素的行为和交互。在设计具有所期望属性的系统时，开发软件构架是第一步。
构架商业周期的概念：系统需求来自于企业目标，构架来自于系统需求，系统来自于构架。构架与设计师的经验、当时的技术水平有着密切的联系。
-
如果知道了系统需求，我们就可以为此系统构建架构吗？这种观点是缺乏元件的，试想一下，如果把某个系统的需求分析文档分别交给2个不同组织工作的设计师，结果会如何呢？这2个设计师是给出同一个架构，还是2个不同的架构呢？
-
答案是：一般情况下，会给出2个不同的架构。这一结果立刻就可以证明系统需求决定架构的观点是错误的。显然，在形成架构的过程中，还有其他的一些因素在起作用，如果找不出这些因素，我们只能在黑暗中进行摸索。 我们关注的焦点问题是：系统的软件构架与构建系统时的环境及系统未来所处的环境有什么关系？此问题的答案就是组织本书内容所遵循的原则。软件构架是技术、商业和社会等诸多因素作用的结果，而软件构架的存在反过来又会影响技术、商业和社会环境，从而影响到未来的构架。我们把这种相互影响的周期--从环境到架构又返回到环境--称作构架商业周期(Architecture Business Cycle,ABC)。
本书详细讨论构架商业周期如下方面：
- 组织目标如何影响需求和开发策略
- 如何从需求得出架构
- 如何对构架进行分析
- 构架如何产生体现新的组织能力和需求的系统
-
构架的产生 构架也是若干商业和技术决策的结果。构架的设计受诸多因素的影响，而这些影响因素的实现又随构架所处环境的不同而异。即使是同一个设计师设计某个系统，在时间要求很紧迫和时间要求比较宽松的情况下，所做的决策也会有所不同。如果对设计没有时间限制，他会做出不同的选择。即使在系统需求、硬件环境、支持软件和人力资源等方面的条件完全相同的情况下，某个设计师现在所能设计出的系统和他5年前所能设计出的系统也很可能是不一样的。
在任何一次开发中，系统需求都能够明确反映出对系统最终特性的某些期望。并不是系统需求中的所有内容都和系统最终具备的特性直接相关。开发过程或某个工具的选用可能会受到系统需求的制约，但对系统需求的表述仅仅是万里长征第一步。如果不能满足除系统需求之外的其他一些要求，所开发出来的系统很可能就像不能正常运行的系统一样一文不值。
我们通过确定与架构有关的影响因素开始构建ABC。
-
构架受系统涉众的影响 很多人和组织都对构建软件系统感兴趣。我们把这样的人或组织称为涉众：客户、最终用户、开发人员、项目经理、维护人员以及那些对系统进行市场营销活动的人等等。这些涉众所关注的问题各不相同，但都要求系统能够在他们所关注的方面提供保证或优化。这可能是要求系统在运行时具有一定的特征、能够在特定的硬件平台上良好运行、用户能够轻松地定制系统、实现短的上市时间或较低的开发成本、使公司雇用到有专长的程序员或提供广泛的功能，如此种种，不一而足。图1.2给出了设计师采纳有帮助的涉众的“建议”的情况。
一个得到各方认可的系统需要在以下方面达到相应要求：性能、可靠性、可用性、平台兼容性、内存的利用、网络使用程度、安全性、可修改性、易用性，与其他系统的互操作性以及行为。上述属性，以及其他一些属性，都会影响此系统的某个涉众对该系统的评价。
最基本的问题是，每个涉众所关心的问题和期望的目标各不相同，而且有些是相互矛盾的。现实情况是设计师通常不得不填补空白并协调冲突。
构架受开发组织的影响 除了通过需求表示的组织目标外，构架还受开发组织的结构或本质的影响。人员的技能也是一个影响因素，开发进度和预算也会对架构产生影响。
开发组织对软件构架的影响可以分为3类，即直接影响、长远影响和组织结构的影响。
- 开发组织可能会对某些资产进行直接商业投资，如现有的构架和基于这些构架的产品。开发项目的基础可能是所有要开发的新系统是已有类似产品线的延续，其开发成本中有很大一部分属于资产重用。
- 开发组织可能希望对某个基础结构进行长期的商业投资以实现某些战略目标，并且可能会把要开发的系统视作为此基础结构融资或进一步扩展此基础结构的手段。
- 开发组织本身的结构也会影响构架的形成。
构架受设计师的素质和经验的影响 设计架构时所做的各种选择与设计师本人所受的教育或培训背景、对其他成功构架的了解以及对某些性能极佳或极差的系统的了解有关。设计构架时，设计师可能想实践一下某种构架模式，或者是尝试使用在某本书上或某门课程中所学到的技巧。
构架受技术环境的影响 技术环境可以看作是对设计师素质和经验的特殊反映。设计某个构架时所处的技术环境将会对构架的设计产生影响。这里所说的技术环境包括行业中的通常做法或在设计师所属专业团体中占主导地位的软件工程技巧。在当今的技术环境下，如果有哪个设计师根本就不考虑用基于Web、面向对象和支持中间件的方法来设计信息系统，我们就不得不佩服他的勇气了。
影响构架的其他因素 影响构架的因素有很多。一些只是隐含的，还有一些则很明显是冲突的。软件开发者几乎从来没有真正理解过企业目标所要求的系统性能，更不必说完全实现了。确实，连客户的需求都很少完全编成文档，这意味着还没解决不同涉众目标之间不可避免的冲突。
设计师需要尽早知道并理解特性、源以及对项目的限制的优先级。因此，设计师必须确定出各类涉众，并积极促使他们表达出对系统的需求或期望。如果不做这样的工作，在设计展开后，就会出现某些涉众要求设计师解释为什么不采用所提出的其他方案的情况，这显然会影响项目的开发进度，降低工作效率。如果早期工作做得好，设计师就能清楚在设计构架时所应考虑的制约条件，调整对系统的期望，与有关各方商讨各因素的优先级并进行权衡。构架评审和迭代原型建立是实现此目标的两个手段。
要设计好的构架，设计师仅具有高超的专业技术是不够的，这个道理显而易见。设计师需要不断地向涉众解释针对不同属性所做的各种取舍，以及为何无法满足涉众的所有要求。因此，成功的设计师还必须具备与人交往、谈判和交流的技巧。 图1.3给出了对设计师（因此也是对构架）的影响。如图所示，设计师会受到产品需求（从涉众那儿获得）、所在开发组织的结构和目标、可利用的技术环境及自身的素质和经验的影响。
-
构架对诸影响因素的反作用 本书的主旨就是要阐明企业目标、产品需求、设计师的经验、构架和最终系统之间的关系--它们构成带有反馈回路的、可由开发组织实施管理的周期。开发组织对这个周期管理得好，就能够不断成长壮大，拓展其经营范围，充分利用以前在构架和系统构建方面的投资。图1.4给出了该周期中的这些反馈回路。可以看到，有些反馈是来自构架本身的，而有些则来自根据构架所构建的系统。
下面我们就来看一下该周期是如何运作的：
- 构架影响着开发组织的结构。构架规定了系统的结构。特别地，就像我们将会看到的一样，构架规定了必须实现（或获得）并集成在系统中的软件单元。这些单元是开发项目的结构的基础。每个软件单元都要由专门的开发小组来完成，开发、测试和集成工作都是围绕这些单元展开的。同样，进度和预算也都要和这些组件相对应，并为之分配所需的资源。如果某个开发公司擅长构建相类似的系列系统，它就会为每个小组进行适当的投资，以保证各小组在其从事的领域达到较高的水准。这些小组也就称为该开发组织中不可或缺的组成部分。这就是从构架到开发组织的反馈。
- 构架会影响开发组织的目标。成功地开发出一个系统，可以使开发公司在相应的市场上占有一些之地。该系统的构架又可以为类似系统的有效生产和部署提供良好的机会，组织可以调整其目标，以利用其新发现的技术来拓宽市场。这就是从该系统到开发组织以及它所构建的系统的反馈。
- 构架可能会影响可会对下一个系统的要求。这是因为与完全重新开始设计相比，利用已有的构架可使客户更为及时地获得更可靠、更经济的系统。从经济的角度考虑，客户可能会愿意放弃某些性能需求。套装软件提供给广大用户的解决方案并不是针对某个用户开发的，但这种软件价格低廉，而且（综合考虑）质量较高。产品线对那些不能确切表述自己在各种情况下的需求的用户也产生了类似的影响。
- 构建系统的过程丰富了整个开发团队的经验，从而将影响设计师对后继系统的设计。
- 一些典型的系统会影响并实际改变软件工程的发展，也就是系统开发人员学习和实践的技术环境。
上述以及其他反馈机制构成我们所称的构架商业周期。图1.4所示的构架商业周期向我们展示了开发组织的业务和文化对软件构架的影响。而构架反过来又成为影响所开发系统各方面属性的决定性因素。但我们也应当认识到，构架商业周期还与精明的开发组织利用开发构架时所做的组织上的或技术经验上的效应有关，这些组织通常会适当调整企业经营策略，以适应未来项目的开发。
软件过程和构架商业周期 我们把对软件开发活动的组织、规范和管理称为软件过程。在创建软件构架，使用该构架实现设计，然后实现或管理目标系统或应用软件的演变的过程中，涉及到哪些活动？这些活动包括
- 为系统构建一个商业案例
- 理解系统需求
- 创建或选择构架
- 将构架编成文档，并与有关各方进行交流
- 对此构架进行分析和评价
- 根据此构架实现系统
- 保证系统实现符合构架的要求
构架活动 就像构架商业周期的结构所显示的那样，这些活动之间存在着复杂的反馈关系。下面我们就对这些活动逐一进行简单的介绍。
- 为系统创建商业案例。创建商业案例的含义要比简单地评估某个系统的市场需求广泛得多。这是创建并限制任何未来需求的重要一步。该软件系统定价将会是多少？其目标市场是什么？预期于什么时间正式推出？是否需要与其他系统连接的接口？有什么必须要遵从的限制条件？ 这些问题的解决必须要有系统设计师的参与。当然这些决策不能仅靠设计师来制定，但如果在创建商业案例的过程中没有设计师的参与，将无法实现这些商业目标。
- 理解需求。可以使用很多技巧获取涉众的需求。 创建原型是另一种有助于理解系统需求的有效方法。原型有助于对所期望的行为进行建模，有助于设计用户接口或分析资源使用情况。这可以使涉众对所开发的系统及早有一个“真实”的体验，从而促使很快做出关于系统的设计和其用户接口设计的决策。 在获取系统需求时无论采用什么技巧，所有开发系统的期望的质量属性都会确定其构架的形状。设计师长期以来一直使用具体的的战术来实现特定的质量属性。构架设计包含了许多权衡，在指定需求时，并不是所有这些权衡都是明显。直到创建了构架后需求中的某些权衡才会变得明显，并迫使确定出需求优先级。
- 创建或选择构架。 在里程碑式的书籍《人月神话》中，Fred *s以令人信服的论证清楚地阐明：概念完整性是成功设计系统的关键，而只有通过以小组的形式共同设计系统构架才能真正实现概念完整性。
- 构架的交流。 要使构架真正成为系统设计的砥柱，就必须向与构架有关的所有涉众清楚而准确地表述构架。为此，构架文档的信息必须丰富、确切清楚，要保证具有不同教育背景的相关人员都能理解。
- 构架的分析和评价。 在任何设计过程中都会有多个候选的设计方案。以一种合理的方式在这些方案中进行选择是设计师所面临的最大挑战之一。
- 实现基于该构架的系统。 这个阶段的主要任务是，保证开发人员在实际开发中忠实于构架所规定的结构，遵守关于各部分之间交互的约定。表述清楚并为各方所理解的构架是保证实际设计与构架一致的重要条件。如果能有一个帮助设计人员创建并维护构架的环境或基础结构，这一阶段的工作就会做的更好。
- 使构架符合原来的表述。 最后，当构架已经创建完毕并投入使用时，开发工作就进入了维护阶段。在这一阶段，要始终保持清醒的头脑，以保证构架符合原来的表述。
什么样的构架才算好 构架并不是注定是好的或是坏的。各种构架总是能够或多或少的满足某些系统的要求，但是，在设计构架时必须遵循一些实践准则。当然，忽视某一条准则并不一定意味着所设计的构架酱油知名的缺陷，但至少应当把准则当作一个警示，进行相应的研究分析。
我们把从软甲开发中所得到的经验分为两大类：关于过程的建议和关于产品（或结构）的建议。我们所提出的关于过程的建议主要有如下几条：
- 构架的设计应该由一位0设计师来完成，或者由一个在某位设计师领导下的小组来完成。
- 设计师（或构架小组）应全面掌握系统的功能需求，并且应有一份所设计构架应满足的划分了优先级的质量属性列表（如安全性或可修改性）
- 构架的文档应该完备，至少应有一个静态视图和一个动态视图，应该采用所有人都认同的文档形式，以保证所有涉众都能够理解这些文档
- 应该把构架设计方案交由所有涉众传阅，让涉众积极参与设计方案的评审。
- 应该对构架认真进行分析，得出可应用的量化度指标（如最大吞吐量）。也应该对质量属性进行正式评估，以避免出现发现问题时为时已晚的情况。
- 构架的设计应有助于增量式实现。为此，可先创建一个粗略的、具备雏形但功能最简单的系统，通过这个骨架系统逐步细化、扩大来得到所期望的系统。这种做法可简化集成和测试的工作
- 允许构架带来一定的（少量的）资源争用，但应清楚地给出这些资源争用的解决方案，告之于有关各方，并保证这些解决方案切实可行。
我们所提出的关于结构的建议主要有如下几条：
- 构架应采用定义良好的模块，各模块的功能责任划分应基于信息隐藏和相互独立的原则。信息隐藏模块应该包括那些封装了计算基础结构特性的模块，以将大部分软件与计算基础结构的变化隔离开。
- 应该使用特定于每个属性的众所周知的构架战术来实现质量属性。
- 构架绝对不可以依赖于某个特定版本的商业产品或工具。如果确实依赖于某个商业商品，则要合理设计构架，使得当所依赖的商业产品发生变化时，能够方便、经济地适应。
- 应将产生数据的模块和使用数据的模块分离开。未来的变化往往仅限于数据的产生或数据的使用，所以，这样做一般可以提高系统的可修改性。如果系统中需要添加新数据，则这两个部分都要做相应的修改，但如果这两个部分是相互独立的，就可以对系统进行分阶段逐步（增量式）升级。
- 对于并行处理系统，构架应该采用定义良好的进程或任务，它们未必反映模块分解结构。也就是说，有些进程的运行涉及刀若干个模块，而模块中的某个过程可能也要为若干个进程所调用。
- 每个任务或进程的编写都要考虑到与特定处理器的关系，并保证能够方便地改变这种关系。
- 构架应该采用少量的、简单的交互模式。即在整个运行过程中，系统的功能应保持一致。这可使系统易于理解，有助于缩短开发时间、提高可靠性、增强可修改性。它还应该展示构架中的概念完整性--虽然无法度量，但却有利于系统开发的顺利进行。