在牛津高阶词典（第7版）中，架构（architecture）一词的解释是：the design an structure of a computer system，而架构师（architect）一词的解释是：a person who is responsible for planning or creating an idea, an event or a situation。

针对于企业应用，依据不同的关注点，架构可以分为如下几类：

业务架构（Business Architecture）：关注于业务及其流程；

应用架构（Application Architecture）：关注于应用系统设计；

基础架构（Infrastructure Architecture）：关注于基础技术；

数据架构（Data Architecture）：关注于数据存储及其规划；

这里所说的企业应用架构，即属于应用架构，包括如下几个部分：

1.目标和愿景。即应用系统所面临的问题域。

2.评价指标。从哪些纬度和指标来评价和度量解决方案。

3.原则和方法论。为解决这些问题，所采用的原则及其方法论。

4.技术架构。架构的技术层面，给出相应的设计以及结构，描述应用系统。

5.组织因素。架构的组织层面，组织的各个部分如何参与。

二、架构的目标和愿景

1. 架构的问题来源

A.     外部，客户要求包括了业务和技术上。

B     内部，组织管理、项目管理和技术发展上。

特别的，架构需要解决的非业务问题包括如下：

a系统目标：系统性能，稳定性等。

b.项目目标：开发成本，项目质量等

c.项目过程：需求的不确定性和开发过程的团队协作性，即所谓的开发管理。

2. 架构的核心问题

问题可分解为两种类型，业务上和技术上。

A 业务上。问题域分解为，逻辑的纵向抽象层次，以及逻辑的横向模块分解和集成。

B 技术上。问题域分解为，纵向的技术主题，以及横向的技术职责的分解和集成。

a领域化

传统的架构模式是三层或者四层模式，虽然从技术上有效的横向分解系统结构，但对业务模型如何建立，如何进行层次间传递，模型间关联关系，以及与服务逻辑耦合等问题没有给出进一步的细化，也带来了很多问题。

此外，在传统设计方法下，分析模型和设计模型的转换也是一个大的问题。

b组件化

实施组件化或者说模块化，其需求分为两个层面。

b1.内部管理，可以帮助开发过程中进行业务切分，帮助控制进度，降低风险，以及财务分析；对于大型复杂的项目，也有利于知识的传递和积累。

b2.销售需要，All in one的系统因不符合发展趋势而不利于销售；组件化有助于产品销售，可以针对客户，将若干组件打包销售，同时减少集成的风险。

c.产品化

c1 定制化问题

定制化问题的由来：1.面向行业的应用通常没有标准，或者完备的标准；2.通常产品的开发是针对于通用或者公共需求，不针对于特定客户；3.而一个确定的客户，其自身的业务差异和管理差异导致需求的差异性。

这种现象尤其在缺乏标准的行业应用中，以及系统的产品化过程中。

传统的简单的解决方式是为每个客户单独维护一个系统分支，在此情况下提供维护和升级，则维护成本巨大；因此如何解决领域的定制化就成为一个重大问题。   

c2 升级问题

领域需求每次进一步的挖掘和实现，都意味着领域的升级。但升级面临的诸多问题:数据迁移,旧版本的兼容问题，依赖关联等等，在组件化和定制化情况下，还面临定制化兼容和冲突检测。

c3 国际化问题

1.文本消息国际化

国际化消息没有直接呈现，而是中间存储后呈现；

2.布局国际化

阿拉伯人是从右到左；

3.业务时间，跨时区；

4.计量单位，多币种；

d.平台化

应用系统可以分为两个内容：应用程序和基础设施。应用程序处理业务问题，而基础设施处理技术问题。

来自客户的要求是包含业务和技术两个方面。其中技术上包括两种“定型和定性”，其所需的知识和技能是不同于业务上的；

此外，内部管理也提出相应的要求。由于技术的发展和业务发展之间的不同步，对于一个产品而言，同时存在技术升级和业务升级两个需求。而同时升级存在较大的成本和风险。

同时对于一个产品来说，技术方面需要较强的适应性，能够低成本上的适应客户的特别要求。

因此有效解藕技术和业务两个部分成为必然。

3.架构的应用问题

A.事务管理

数据一致性问题出现的原因通常是开发过程中，由于错误的并发和事务控制导致的；而在业务过程中也存在错误的业务操作情况。

B.并发处理

不同的业务应用存在不同的并发场景（并发度以及存在的业务依赖），因此业务上需要明确原则和方案；而不同平台所支持的并发方式和能力也不相同，则采用一定框架支持有助于简化问题。

C.集成能力

业务应用所面临的集成问题不同，包括不同的集成环境：外部系统，内部系统，遗留系统等；不同的集成模式：基于文件，基于数据库表，基于消息等，导致所需的集成方法及其能力也不同。

4. 架构的设计问题

分析设计和开发实现存在着一定的差异性：分析设计属于知识级，而开发实现属于操作级的。

分析设计是需求和实现的中间桥梁，因而设计必须解决系统边界的合法性，内部逻辑解藕的合理性和实现的可达性（设计的类方法为实现的30%-70%）。而开发实现需不断重构代码，采用约定和框架能力等技术手段解决开发的实际问题，解决程序级别的健壮性，可读性，可维护性以及可测试性。

传统的方式，分析设计存在于文档中，而开发实现存在于代码中。两者的割裂导致沟通的困难，也导致了开发工程中具大的风险——分析设计和最终开发实现的不一致性。

三、架构的评价指标

1. 财务角度

在传统的财务核算机制中，系统或者产品的开发通常属于成本中心，对于IT企业来说，电脑设备，办公室等属于沉没成本，而IT人员的工资属于可变成本，是成本的核心部分，为了控制成本，就需要减少项目的开发时间。

因此架构一个重要的关注点在于控制开发成本和维护成本，通常讲维护成本是开发成本的3倍。降低开发成本核心，在于提高效率、提高适应需求变化的能力。

2. 技术角度

技术角度评估架构很难说一个架构行或者不行。技术角度需要给出的最大指标是风险性。而风险性和各个指标因数有很大相关，但还需要结合相应实际情况判断。例如：如果决定了不可能换数据库，那么即便强绑定oracle也没有特别的风险。

以下指标参考了架构的质量特性，但进行了裁减。

A.内部指标

1.侵入性。或者说是可迁移性，即系统与外部资源的关联关系，以及系统内部的关联关系。例如，如果架构决定使用pl/sql，那么就意味着架构和Oracle数据库是强绑定。

2.重复性。虽然我们都知道关于重复的两个原则（1.不要重复，2.不要自己重复），但是有时重复看上去无法避免，那么就是判断这个重复性带来的问题有多大。

3.扩展性。即架构提供何种条件下的何种扩展和变化能力，及其成本。

4.平稳性。在业务或技术扩展时的，架构所呈现的发展态性。

5.抽象性。即可视性，并包括了概念完整性。系统是否完整以及层次化的反映应用问题，能否明确的呈现和表达。

6.修改性。包括了可重构性，代码级别的侵入性以及单元测试能力。

7.诊断性。系统提供的实时观测能力。

B.外部指标

1.性能。

2.可靠度。

3.可用度。

3. 组织角度

组织角度涉及两个方面：人和流程。

人的方面，架构需要组织的角色参与（业务专家，技术专家）及其参与度，以及涉及到人力资源匹配情况。若架构所需的技术如果太新或者太窄，将面临人力资源的困境。

流程上，要看架构是否与流程匹配。架构原则指导下不同角色在不同阶段关注点不同，而工程实践中，不同流程阶段需要提交的产出物也不同，此时就可能存在二者不匹配的情况。

四、架构的原则和方法论

1. 原则

总原则是：关注点隔离。

在解决各类问题都应以此原则为指导。但针对于不同层面该原则的变化不同。针对于高层设计（概要设计）：合理划分逻辑边界；针对于详细设计层面是：任何改动最多涉及一个接口和一个实现类（简单类职责的变体）。

2. 方法论

方法论有两个：自上而下，由内而外。

其对应的完整理论体系为：面向对象/面向方面，领域驱动设计以及测试驱动设计。

3. 发展与演化

A.总结归纳型

这个方式最常见。程序员所需要面对的问题是：在有限的时间、资源，面对有限的需求，在容错范围内的做出一定的产品。在这种有限条件下反复训练出来的决策机制，使得程序员对归纳法有着特殊的偏好。它对于程序员开发的大部分工作都是行之有效的。

B. 技术思辨型

通过更广泛的分析，获取深刻的理解和普遍的关联，以创造新颖的技术。所谓大牛们正是如此。例如GC算法，例如AOP技术。

五、架构的技术层面

（一）基础手段

提高开发效率和品质的基本手段是分解——即充分的分离系统中不同的关注点，好处不用说了，可以并发的工作，每个人面对的问题都简单而容易操作。而与分解对应的集成，只有提供了好的集成能力，分解才成为现实，而只有分解了，才能清晰的提供业务更多适应性。

分解和集成的手段分为编程语言和技术框架两个层面。所谓语言就是强框架，而框架就是弱语言。

A. 开发语言

现代面向对象的语言提供如下能力：抽象和派生能力，以及接口隔离能力。实际提供两种分解和集成能力：

A1.     把逻辑分解在两个层次中，而通过继承的方式把两个部分集成在一起。

A2.     把逻辑的外观和实现分解在两个地方，而通过接口实现的方式把两部分集成在一起。

另一种语言AspectJ或者C#语言2.0之后提供的特性：把流程逻辑，分解在不同的地方，而通过签名匹配，利用代码生成的方式来把几部分集成在一起。

B. 应用框架

然而语言提供的集成能力，毕竟底层，而且有限，扩展起来也格外小心。因而技术框架提供另外的集成能力就格外重要：

B1. 对象关联关系的分解和集成，如Spring提供容器管理能力

依赖注入对于依赖关系是适合的，对于服务间，技术层次间都是适合的（因为无状态）；但对于聚合（整体和部分）的关系——主要是领域模型（有状态的）——则不合适；

B2. 模块间关联关系的分解和集成，如OSGi，ESB等

B3. 流程逻辑的分解和集成，如Spring Web Flow以及jBPM。

B4. 不同系统的类型分解和集成，如Spring利用动态代理提供的Exporter模式。

B5. 模式的封装集成，设计应当是面向服务的设计，但是服务的暴露方式以及模式可以有很多种，比如API，Web Service，RMI，以及Command模式，Event模式等，框架应该利用动态代理等技术对于这些服务暴露方式，模式进行封装。

C. 分析设计

设计中涉及到的组合方式，包括类（接口）组合，继承组合以及产生组合三种。三种组合各有优缺点，设计时适应不同场合。这就涉及到现有面向对象的设计粒度：类（第一公民）和方法（二等公民）。

类（接口）组合实际上复用的是类一级粒度的设计，而继承组合本质上是一种有方向的组合，复用的方法一级粒度的设计，提供与或非的逻辑操作。而产生组合，例如AspectJ，也是在方法一级粒度的设计复用。

因为继承组合复用在方法一级的粒度上，因而其更适合存在嵌入式，最低粒度的差异性的设计中，借助于虚拟机的支持，无需额外工作。而类（接口）在类一级上，更适合在更高一级的逻辑复用上；其实不一定需要接口，普通的类也可以，但是在这一级粒度的差异性替换，采用接口优于类，因此称为类（接口）组合；接口是类（接口）组合的编码需要；对于接口一级，需要通过框架的集成和适配来提供差异性的设计。产生组合其实也是在方法一级，不过更关注于广泛的横切面，同时由于现有的语言对它的支持不同，Java需要额外的编译器，而.Net则是在内置编译器上支持。

更高一级的组合是组件组合。对于组件边界的设计，遵从两点：严格把关设计和代码优先。接口优先的设计通常导致成本太高，实践中会导致开发人员在项目的进度压力下把代码写在不合适的地方。

D. 开发方式

常见的开发方式可以归结为3类：开发式编程（Programmatic programming），声明式编程（Declarative programming）和产生式编程（Generative programming）。

E. 小结

通常语言作为架构的基础，语言的设计带来的好处远远高于框架和模式，但其引入和更换也是有巨大风险的；而通过提供强大的框架能力，框架尽可能多的完成技术问题，并通过元数据，模式以及约定降低业务和框架的耦合。避免因为框架升级带来不必要的成本。

Meta Programming的最高层次是语言级别直接解决，比如，Smalltalk, Ruby, Python, 还有其他Reflection支持的非常好的语言。甚至STL等template技术，也可以算作语言级别。 Code Generation 是最低级别的Meta Programming解决方案,技术含量也最低。这个级别必须超越，才能够真正达到质变，完全跳出概念炒作的层次。

从技术手段上，提高开发效率的另外两个手段是代码生成和类库引用。但代码生成和类库引用，都只解决了逻辑的分解能力，没有提供集成能力，所以一般情况下需要提供框架集成，尤其代码生成需要在系统的最外层，避免集成带来的问题。

代码生成也没有那么坏，关键在于生成什么，如果是生成结构性的代码，由于往往不是最终的产物，就存在同步维护问题；同时这种代码是大都可以用template完成的。

但如果生成的是功能性代码，这类代码是最终执行代码，那么通常就把用于设计的代码看作是最终产物，最明显的例子是DSL。

（二）核心问题

1. 领域化

领域化，即领域建模。通常而言，领域模型设计中，模块分解，抽象分层和职责分层都是重要手段。问题域为：流程，领域模型和领域服务（包括规则）。

a. 对象的抽象分解和集成

b. 对象的依赖分解和集成（模块内和模块外）

c. 流程的分解和集成（页面流，工作流以及计算流程）

d. 进程边界：用户请求重定向，以及业务数据持久化等。

对于中等项目来说，系统中应该有50-100个领域对象代表了业务抽象；

2. 组件化

面向对象语言本身没有提供的组件级别的依赖关系集成能力。语言不提供，因为领域组件的粒度太大，超越了语言的范畴。但我们可以通过框架提供，在Java体系中，目前已经有两个较好的解决方案：OSGi（JSR291）和SCA。可以很好的解决组件服务依赖关系管理，包括热替换。

同时另一个问题——逻辑分层的问题：如保险产品面临的核心层，国家层以及公司层三个逻辑层次分解和集成能力。这点的解决方案可以通过OSGi + Spring来解决，包括了静态差异性替换和动态差异性替换。

还有组件边界保护问题，我们希望限制别的组件访问本组件内部实现，有两种手段可以完成，1是提交/部署时，通过在代码提交时的代码检查工具，或者发布时编译工具完成；2是通过OSGi的边界限制能力。

3. 产品化

A. 定制化支持

领域定制化涉及到逻辑替换问题。逻辑的替换根据开发方式不同，有两种类型：基于接口和基于继承；

a. 基于接口（包括了静态替换和动态替换）

a1. 静态替换是Override，在OSGi中只要停止原有服务，启用新服务即可，而在Spring中更改相应配置文件即可；

a2. 动态替换，其实是指运行时Condition Service Locator，在OSGi中可以利用Extension Point（Plug-in）解决，而Spring中只要提供一个类似Service Locator就可以。

b. 基于继承（或者静态类）

b1.开发时，直接修改源代码编译；

b2.编译时，采用AspectJ，在编译时提供替换；

b3.加载时，开发一个新逻辑的同名类，但其加载路径优先于原有类；

B. 升级支持

主要是增量升级支持，以及有限的降级支持。同时要考虑到对于定制化产品的升级支持。

4. 平台化

A.基础设施               

基础设施包括：类库和框架。基础设施可以自己开发，或者应用第三方（开源商业）实现。

A1. 基础设施的选型

应考虑几点：1. 商业角度的可维护性和可升级性；2. 组织的学习和管理能力；3. 基础设施自身功能以及所支持的开发效率。以下是详细要求：

A2. 基础设施的集成

基础设施独立后，出现平台化的发展趋势，这个趋势有两个方向：通用化和专业化。通用化意味着基础设施和应用的距离加大，易用性减低；而专业化意味着适应性的减少。这是一个矛盾体。在基础设施选型后，再进行一定集成工作，可以结合当前情况，平衡易用性和适应性；同时合适的集成也有助于隔离技术和业务两个方面。

从维护升级角度看集成的合适性：对于没有标准的，不要做不必要的封装，封装等于是建立一个标准，而这是不现实的；应当尽可能采用框架方式，屏蔽基础设施对于应用程序的侵入性。如果是标准，就更没有必要封装，画蛇添足。

B.业务支持

B1. 基本原则和手段

基本原则是：应用程序POJO化。减少技术对于业务侵入性。主要手段是：容器上下文；依赖注入；AOP技术；元数据支持；事件机制；开发工具和代码生成；

依赖注入+AOP+元数据构成了简单对象(POJO)的支撑技术。基于此三位一体的技术可以有效的隔离业务问题和技术问题，更为甚者它可以支撑简单对象体系，每个对象做且只做一件事。

B2. 开发模式与最佳实践

基础平台应该提供业务相关的模式封装。

B3. 关于元数据

元数据有多种：语言级别为Annotation(微软.NET为Customer Attribute)；框架级别可以是XML文件或者其它配置文件。

元数据可以通过以下几个视角观察

1. 应用层次：元数据代表了业务含义和技术含义；

2. 技术分析：文档类型（开发管理型）；编译类型（类加载型）；运行期行为。

3. 物理分析，包括Annotation和接口，XML文件，甚至是EL和类。

元数据系统的建立其实是代表了认知过程。

以运行期的元数据为例，代表了系统通过反射获取相关元数据来自适应系统，其实际意义在于将软件设计开发人员对于系统的认知通过技术手段固化下来。

元数据系统的开发目的有两个：

1. 业务应用上，提供业务动态能力；

2. 技术应用上，简化开发减低成本；

这里面有一个误区是：为了技术应用而过分地开发元数据系统，而随着业务的演化导致为技术应用的元数据迅速被抛弃，导致投入的浪费。实践中要避免。

（三）应用问题

1.事务管理

a. 成熟的事务技术：如数据库；

b. 合理的并发设计控制；

c. 完整的业务日志；这也是解决业务回退的主要手段；

d. 辅助的数据校验能力；

并发设计控制和完整的业务日志，是架构设计中保障数据一致性主要着力点。并发设计控制，需要结合业务，通过悲观锁定来保障。

而业务日志的获取则面临着诸多困难，主要是业务事务和物理事务的不一致性（即一个业务事务可能横跨多个物理事务，也可能一个物理事务包括多个业务事务）；业务日志控制层面有两个：应用系统或基础设计；通过应用系统编码控制，则不可避免的提高了应用系统开发和测试的成本；通过基础设施控制，有助于减低成本，但提高基础设施的设计成本；

3.系统分解

基于应用的层面的分解，有多个纬度，包括：业务抽象度，业务任务，业务产品线，以及业务领域等等。

4.集成能力

软件开发的适应性在于分解粒度的大小，而分解粒度大小取决于集成能力。

A依赖管理

在技术的角度看，软件系统是一个存在大量依赖关系的对象系统。其中包括了两种依赖：

A1.业务代码的对象依赖；比如调用一个工厂类创建一个对象。

A2.业务代码的环境依赖；它可能依赖于一个Web环境（读写Request和Response流），数据库系统（读写数据记录），文件系统和网络系统等。

不幸的事是这种代码量占据了大量的开发工作。重复的开发工作（对象或者数据的依赖关系维护工作）减低了开发效率和系统适应变化的能力。

而这样复杂依赖关系也给软件的测试带来了相当大的困难需要搭建足够的依赖环境（如一台Web服务器和数据库服务器），甚至是硬调试。

于是就有了采用第三方代码来完成依赖关系维护工作的思路，所谓的依赖注入。业务对象出现Spring等著名框架

动态代理技术则解决了提供支撑环境封装的问题。比如提供网络访问能力(如RMI，URL和Web Services)，文件访问能力(如xml、property文件读写)。

由于企业开发中数据库技术的应用不可避免，因而ORM框架的出现还有特别的意义，在它的支撑下，核心业务西可以严格区别领域逻辑和业务逻辑，而这在以前是做不到的。

AOP开发的出现解决了面向对象下的横向组织关系。从一定程度上看，AOP可以看作是另一种依赖关系，可以另外依赖注入来实现。当然也可以采用编程实现。

B数据对象

说起集成，就不得不提到一种类型的对象存在——VO对象。

VO对象是为了集成而存在的；其意义是：1. 保护系统的信息边界，提供一种结构可以使其它系统或者组件通过编码方式获取系统内信息的方式；2. 保护系统的事务边界，领域对象技术上携带着持久化信息，通过VO可以屏蔽得以屏蔽。常见的VO对象存在于Web层和Domain层。

因此，VO对象的存在只是为了集成而存在，其是否存在的取决于两个方面1. 集成的设计结构；2. 框架的两个能力——对象路径访问能力以及事务边界管理。

Domain层VO对象，通常是用于不同领域组件间的交互，但随着架构的改进，集成代码独立存在而不再嵌入到组件内部，组件的边界问题保护不复存在；更进一步的是，框架提供自动化的接口适配映射能力的增强。因而VO对象失去存在的意义。

Web层VO对象，以SWF为例，早在SWF 1.x时代，框架就提供了丰富的对象路径访问能力，但其Web交互是典型的MVC2方式，事务边界在view的render前关闭，因而导致需要特定的VO对象来避免持久化信息问题；而SWF 2.x时代，view的render是在事务边界内，VO不再需要。

系统设计是一种结构化过程，逻辑和数据被分解和集成到系统的各个部分；在运行期，真正重要的是结构化路径访问能力，换句话说重要的是结构化后的路径，而实际用何种数据结构其实不重要。

可以使用数据树Data Tree形式，提供扁平化的数据访问能力，是一种较好的开发方式，极大的提升了开发效率。Spring Web Flow以及其它框架广泛的运用EL提供统一的表达式访问数据，也大大降低了开发成本。

C事件机制

事件机制应用非常广泛，是很重要的集成手段。事件机制的优势在于其提供了松散耦合而带来的扩展能力。基于传统事件模式，可以扩展提供同步/异步，事务隔离等额外控制能力。

D组件设计

一个组件包括了API和SPI，其中API是用于客户方编程，SPI用于服务方编程（属于框架回调）。无论是API和SPI都是该组件所有，体现了一个组件自身的完备性。其与其它组件依赖通过集成模块完成，依赖解藕。

组件的设计还分层次，上层组件的逻辑依赖下层组件，上层组件直接访问下层组件的服务和模型，保持单向依赖有助于降低开发和维护成本。而平级组件，由于组件的替换可能性大，因而保障组件边界完整性尤为重要。

接口的实现是关键。面临的问题是，在开发初期需求不确定和经验不足的情况下，接口的设计不尽合理，导致需求变动后，所进行的修改将影响三个方面，接口、接口实现对象和测试用例。工作量将可能很大。特别是在并行开发过程中，一个通讯接口的变化将可能引起很大连锁反应，导致其他成员不得不停下手上的工作。

因而在实际开发中需要做个权衡。不同模块的通讯接口应该由团队成员共同负责，一旦接口变化，接口实现成员应该提供相应的假实现。而模块内部可以由开发人员自行设计，可以在初期不提供接口和简单的测试用例，在项目具有一定稳定性后，利用重构实现接口和完整的测试用例。

有效定位系统错误。尤其在组件化和分层化，以及其它开发手段混合运用情况下。例如，A，B，C。由于C引起的错误导致A错误

六、架构的展示

1.两个要素

架构要展示的两个基本要素是：业务和技术组件。而业务又可分为组件和功能两个层次，技术又可分为基础平台与组件所需提供工件两个部分。

后续所有展示都围绕此二要素。

2.核心视图

由RUP贡献的四个视图是架构展示的核心视图。

a逻辑视图（静态类图）

关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们可能是逻辑层、功能模块等。

应映射为业务组件、功能包以及技术工件（分层），以及它们之间关联依赖关系；

b开发视图（静态类图）

关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。

开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。

应映射为具体的SDK和框架等，以及关联依赖关系；注：开发视图应尽可能和逻辑视图一一对应；

c处理视图（动态类图）

关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。

处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。

可映射为状态图和活动图（高层和详细）；

d物理视图（部署视图）

关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。

物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。

可映射为组件图，部署说明图；

3.扩展视图

在核心视图，针对于不同受众，还需要提供三个扩展视图。

a非功能视图

展示非功能性指标的支持能力。通常针对于技术人员。

b基础设施视图

展示架构所采用基础设施，以及它们之间的关系。通常针对于技术人员。

c数据视图

关注于数据组织和存储形式。通常针对于DBA，或者需对数据进行定期维护的用户。

4.原则和约束

架构因明确说明本架构采用原则、方法论以及相关约束。

5.技术选型分析

由于架构涉及众多底层技术，也应给出相应的选型分析。

“NET框架是一个基于XML的平台” 不敢苟同，从哪个方面说是基于XML的平台，这句话太不准确了，的确里面很多地方是用了XML，但“基于”这个词可不能随便用，“XML”在.NET框架中只是一种简单的数据保存格式，其核心远不在XML