本文是文章Microsoft Architecture Overview的翻译和阅读笔记。
这是2002年7月的文章，作者为Michael Platt。
本文档面向希望了解微软企业、应用和技术架构方法的业务、软件和基础设施架构师。它涵盖了架构术语、模式、概念和定义，以一系列架构视图或层级呈现。
Enterprise Architecture
ANSI/IEEE Std 1471-2000 中对架构的定义为："系统的基本组织，体现于系统的组件、组件之间以及组件与环境之间的关系，以及支配系统设计与演进的原则。"
💡 ANSI/IEEE Std 1471-2000 中对architecture的定义原文为：
the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
💡 架构前面是有很多定语的，如系统，软件，企业等。在以上定义中，由于其指明了是of a system，所以这里的架构指的就是系统架构。
最新的系统架构的定义参见这里：
System architecture is the fundamental organization of a system, embodied in its components, their relationships to one another and to the environment, and the principles guiding the system's design and evolution. The formal definition originates with IEEE Standard 1471:2000 and its successor ISO/IEC/IEEE 42010:2011, which standardized the vocabulary and framework for architectural description across systems and software engineering. A system architecture encompasses both structural decisions (what components exist and how they connect) and behavioral decisions (what each component does and how the system responds to stimuli), with the explicit goal of satisfying stakeholder concerns regarding function, performance, safety, and evolvability.
系统架构是系统的基本组织，体现于系统的组件、组件之间以及组件与环境之间的关系 ，以及指导系统设计和演进 的原则。该正式定义源自 IEEE 1471:2000 标准及其继任标准 ISO/IEC/IEEE 42010:2011，后者为系统工程与软件工程领域的架构描述统一了术语体系与框架。系统架构同时涵盖结构性决策 （存在哪些组件、组件如何互连）和行为性决策 （每个组件承担什么功能、系统如何响应外部刺激），其明确目标是满足利益相关方在功能、性能、安全性和可演进性方面的关注。
System architecture as a discipline draws on electrical engineering, computer science, control theory, and industrial engineering. It addresses both the hardware and software subsystems of a technical product as well as the interfaces between them, making it a bridge between high-level requirements and detailed design. A well-specified architecture constrains the implementation space sufficiently to allow distributed teams to work concurrently while ensuring the integrated system will satisfy its intended function.
系统架构作为一门学科，借鉴电气工程 、计算机科学、控制理论以及工业工程 的知识体系。它既研究技术产品的硬件子系统与软件子系统，也研究各子系统之间的接口，是连接高层需求与详细设计的桥梁。一份定义完备的架构能够对实现空间做出充分约束，使得分布式团队可以并行开展工作，同时保证集成后的系统能够实现预期功能。
企业架构（EA）是一种概念化工具，用于帮助组织理解自身结构与运作方式。它提供企业全景视图，也是业务与技术变革的规划向导。
💡 架构的目的在于沟通，架构师大部分的工作也是在沟通，以在众多的干系人之间做出平衡。
企业架构通常由一套完整且相互关联的模型构成，用以描述企业的结构与功能。其核心用途包括系统化信息技术规划与架构设计，以及辅助优化决策。
企业架构中的各个模型按逻辑层次组织，由粗到细逐层展示企业信息，涵盖：
- 企业目标与愿景
- 业务流程与组织架构
- 信息系统与数据
- 所采用的技术
💡 上面4点其实就是TOGAF中的战略，业务架构，信息系统架构（应用+数据），技术架构。
Microsoft Architectural Perspective
企业架构中的信息可从多个视角进行查看，能够满足多样化需求。架构使用者包括业务经理与业务分析师、系统架构师与设计人员、工作流及流程分析师、物流专员、组织分析师等。这些人员既需要高层汇总信息，也需要详细数据，以及介于两者之间各级粒度的信息。可通过构建概念视图、逻辑分析与物理实现，来满足上述各类需求。
在微软，我们认为有四类通用视角十分重要且被广泛使用，分别是业务视角、应用视角、信息视角和技术视角。
The business perspective
业务视角描述业务的运作方式。它涵盖宏观业务战略，以及将组织从当前状态过渡到设想的未来状态的各类规划。业务视角通常包含以下内容：
- 企业的高层目标与愿景
- 整个企业（或企业重要组成部分）所执行的业务流程
- 所承担的业务功能
- 主要组织结构
- 上述各要素之间的相互关系
The application perspective
应用视角以应用系统为核心，定义企业的应用资产组合。该视图通常包含：
- 支撑业务流程的自动化服务说明
- 组织内各应用系统之间交互与依赖关系（接口）说明
- 根据企业目标以及不断演进的技术平台，制定新应用开发与旧应用改造计划
应用视角可体现跨组织的服务、信息与功能，将具备不同技能、不同岗位职能的用户关联起来，以达成共同的业务目标。
The information perspective
信息视角描述组织为执行业务流程与运营活动所需掌握的信息内容。它包含：
- 标准数据模型
- 数据管理策略
- 组织内部信息产生与消费模式说明
信息视角同时描述数据如何融入业务工作流，涵盖数据库这类结构化数据存储，以及散布在整个组织中的文档、电子表格、演示文稿等非结构化数据存储。
The technology perspective
技术视角列出支撑组织运转的硬件与软件，包含但不限于：
- 桌面端与服务器硬件
- 操作系统
- 网络连通组件
- 打印机
- 调制解调器
技术视角对支撑应用视角与信息视角所必需的基础设施和系统组件进行与厂商无关的逻辑描述。它定义执行业务使命所需的一套技术标准与技术服务。
尽管可以存在众多视角，但所有视角所观察的企业架构只有一个。企业架构的价值不在于任何单一视角，而在于各个视角之间的关联、交互与依赖关系。
虽然所有视角都是企业架构的核心要素，但本文档将重点关注应用视角与技术视角。
Application and Technology Architecture
软件系统的功能需求描述软件所能提供的业务价值。以气象服务为例，一条功能需求可表述为："若输入格式合法的消息 A，该服务将返回消息 B，消息 B 的内容与消息 A 中指定的时间段和地理位置匹配。"
应用架构是支撑并实现上述功能需求的各类自动化服务的架构，包含面向业务以及对接其他应用的接口。它描述应用的结构，以及该结构如何实现组织的功能需求。理想情况下一个组织应当只有一套应用架构，但在实际场景中，通常会存在多套不同的应用架构。
软件系统的运行需求定义软件在可靠性、可管理性、性能、安全性、互操作性等方面的要求（此处仅列举部分）。典型例子：该服务仅对授权订阅用户开放，服务可用率达到 99.999%。
技术架构是支撑组织、实现**运行需求（或称非功能需求）**的软硬件基础设施的架构，重点支撑组织的应用架构与信息架构。它描述所使用各项技术的结构与相互关系，以及这些技术如何满足组织的运行需求。
良好的技术架构能够提供安全能力、可用性与可靠性，并可支撑各类其他运行需求。但如果应用的设计未能利用技术架构本身的特性，应用仍然可能性能不佳，或是难以部署与运维。同理，一套精心设计、完全契合业务流程需求，并且基于可复用软件组件、采用最新技术构建的应用结构，也有可能无法很好地映射到实际技术配置上：服务器配置无法适配应用组件，网络硬件参数不能支撑信息流转。
这体现出应用架构与技术架构之间存在依存关系：优秀的技术架构是为支撑对组织至关重要的特定应用而构建；优秀的应用架构则充分利用技术架构，在各项运行需求下稳定输出一致的性能。
Figure 1. Relationships between architectures
Conceptual, Logical, and Physical Views
对于所有架构视角，架构都存在多种视图，通常划分为概念视图、逻辑视图和物理视图。概念视图抽象程度最高，其描述方式一般采用系统使用者（非 IT 专业人员）最容易理解的语言。概念视图用于定义功能需求，以及业务用户对应用的认知视图，以此构建业务模型。
逻辑视图展示系统内部主要功能组件及其相互关系，不考虑功能实现的技术细节。架构师在确定如何满足业务目标与需求时，会构建应用模型 ------ 即业务模型对应的逻辑视图。这些应用模型代表应用架构的逻辑视图。
物理视图的抽象程度最低，展示具体的实现组件及其相互关系。物理视图中的每一项元素，通常经由设计与开发流程，落地实现为软件或硬件系统。该实现视图一般由组织内部的开发或运维团队负责，因此不在本文档讨论范围之内。
Figure 2. Architectural views
在每一个架构层级上，都可以存在（实际上通常也确实存在）多个架构视图；例如，一般每个应用都会对应一份逻辑应用架构视图。
这类视图由多组需求驱动产生，反过来又为设计、开发、部署与运维流程及系统提供输入依据。
Figure 3. Architectural views and patterns
本指南后续内容将聚焦应用架构与技术架构，介绍相关概念，以及构建基于服务的应用所用到的关键模式，这类应用将利用新兴的 Web 服务技术。实现领域包含设计、开发、环境搭建、部署与管理工作，尽管其在完整系统构建过程中至关重要，但不属于本文档的讨论范围。
Application Architecture
如前文所述，应用架构提供三类视图：概念视图、逻辑视图与物理视图。架构师使用这些视图在组织内构建模型，用以支撑并满足业务需求。理想情况下，每种视图仅对应一套模型；但在实际场景中，由于组织与技术的发展演变，同一种视图可能存在多套模型。不过，将这些模型梳理整合为最小集合，是打造高效且具备柔性的组织的关键。
Conceptual view
概念视图用于定义业务需求以及业务用户对应用的认知视图，以此生成业务模型。用例分析、活动图、流程设计、业务实体建模等概念建模技术，有助于对核心业务流程及其所使用的数据进行描述；该描述以业务目标与业务需求为核心，不涉及任何实现技术。
Logical view
架构师在确定如何实现业务目标与业务需求时，会构建作为业务模型逻辑视图的应用模型。这些应用模型代表某一应用架构的逻辑视图。
此时架构师关注应用的整体结构。他们确定数据管理与流程步骤之间的映射关系，基于逻辑消息与执行序列设计模型各组成部分之间的交互，并确定模型应当保存哪些数据与状态信息。
Physical view
应用模型中的每一项元素都需要映射到真实技术的元素上。通过这种方式，应用模型被转化为实现模型。这项工作的一部分在常规开发阶段完成，由程序员将详细业务逻辑编写为代码；但大量实现活动可归类为框架补全，这是一种开发方式：分布式应用与数据管理的大部分基础设施由成熟框架承载，再通过定制化应用逻辑和声明式控制结构对框架进行扩展。框架补全将开发人员从异步消息处理等复杂底层细节中隔离出来，让能力中等的开发人员也能为项目做出有效贡献。
在组织内不同层级上设计并构建上述各类模型，显然需要投入大量工作与精力。此外，模型的正确定义对组织至关重要。错误的架构模型几乎总会引发严重的设计或运维问题，例如可扩展性不足、可靠性缺陷；最坏情况下，甚至会造成项目无法交付，对业务产生负面影响。架构师需要框架与路线图，辅助他们创建和落地这些模型，并尽可能降低因使用错误模型带来的风险。
可向架构师提供两大类架构指导与支撑，用以加快模型构建并降低风险。
第一类是一套架构概念集，它可以实现：
- 统一认知，支撑沟通交流
- 指导特定概念的使用时机与使用方式，并提供概念属性相关信息
- 说明这些概念在何时可以落地与可用，无论是作为指导规范，还是以真实技术形态提供
第二类是一组模式。这些模式从大量成功的分布式应用中提炼真实实践经验，并基于上述基础架构概念构建而成。模式封装了分布式应用设计中的重要最佳实践；通过提供经过验证、成熟可靠的架构模型，能够降低项目失败的风险。
Figure 4. Views of application architecture
Application Architecture: Conceptual View
过去，应用程序是通过集成本地系统服务（例如文件系统、设备驱动程序）构建的。该模型可以灵活地访问丰富的开发资源，并对应用行为实现精细控制；但这种方式极易出错、成本高昂且开发周期漫长。
如今，复杂的分布式应用可以集成网络中已有的各类应用与服务，再基于业务实体、数据实体、外观（façade）等组件叠加独特业务价值。这让开发人员能够聚焦交付差异化业务价值，最终缩短产品上市周期、提升开发人员生产力，并产出质量更高的软件。多年来这一直是一套强大的架构模型；但它会形成应用烟囱 或称信息孤岛，给架构复用带来严重问题。
我们正迈入计算技术的下一阶段 ------ 互联网与 Web 服务共同促成了这一阶段。借助 Web 服务，我们能够构建强大的应用，任何人在任意地点均可使用。它扩大了应用的覆盖范围，支持软件的持续交付。在此背景下，软件就是一种服务：用户通过通信网络订阅并使用该服务。
.NET 实现了这一构想：它融合n 层计算 高内聚、开发效率高的特性，同时吸纳 Web 面向消息、松耦合的设计理念。这种计算模式被称为XML Web 服务。它代表应用开发的下一代演进方向，也是概念层应用架构的实现基础。
Web 服务是独立的应用逻辑单元，对外暴露基于消息的接口，支持跨网络访问。通常，服务既提供业务逻辑，也负责处理对应业务场景下的状态管理。设计服务时，目标是有效封装现实业务流程对应的逻辑与数据；同时要做出合理取舍，判断哪些能力放在本服务内实现，哪些需要拆分为独立服务。
状态变更受业务规则约束。业务规则属于相对稳定的算法，例如根据商品明细计算发票总金额的计算逻辑，一般以应用逻辑的方式实现。
服务由策略（Policy）管控。策略不像业务规则那样固定不变，可能存在地域差异或客户定制化差异，通常在运行时通过查询配置表来加载。
由此可以得到一个更完整的服务定义："服务是具备网络访问能力的软件单元，它实现业务逻辑、管理状态、通过消息完成通信，并且受策略管控。"
关于应用的概念视图，可参考文档： Application Architecture: Conceptual View，其中有更加详尽的介绍。
Application Patterns
模式是特定场景下某个问题的解决方案。模式将从领域实践经验中总结出的特定知识整理固化。应用模式属于架构级模式，针对特定应用环境定义架构设计的最佳实践。
模式存在多种不同类型与分类体系，具体模式的定义与说明不在本文讨论范围内。现有的很多架构模式可以应用于基于 Web 服务的架构；同时，依托 Web 服务提供的新构造，也衍生出若干全新的模式。
Technology Architecture
和应用架构一样，技术架构同样包含三类视图：概念视图、逻辑视图与物理视图。架构师利用这些视图在组织内构建模型，用以支撑并满足运行需求。和应用架构的情形相同，理想情况下组织应当仅有一套技术架构；但现实中，受组织与技术发展演变影响，几乎总会存在多套技术架构。组织的一项核心诉求，就是将这些彼此异构的技术架构整合为一套全局统一 的架构，实现现有应用复用 ，并把多套技术架构梳理精简至最小集合。构建这套统一的公共架构，对于打造高效、有力且具备柔性的组织至关重要。
Conceptual view
技术架构的概念视图用于将各类技术领域规划为一套结构与框架。它对这些技术领域进行定义、命名与定位，使技术提供方与使用该技术的业务组织达成共识；同时确保实现组织运行需求（或称非功能需求）所需的全部技术领域都已明确定义，可供组织使用。
Logical view
技术架构的逻辑视图，定义支撑企业级运行需求的主要功能组件及其相互关系。数据库、邮件系统、事务支撑、可靠消息等企业技术组件，都在逻辑视图中给出。该层级所描述的技术，通常由企业软件厂商打包封装为各类服务器产品对外提供。
Physical view
技术架构中的每一项组件都需要映射到真实软硬件技术组件上。通过这种方式，技术架构落地为由网络、服务器、操作系统等构成的完整系统。该层级会展示实际物理位置、服务器产品型号以及网络连接关系。
架构师期望 IT 厂商提供技术框架与路线图，以协助搭建满足组织运行需求的系统，并保证本组织的技术架构与 IT 厂商的技术架构保持对齐。
Technology Architecture: Conceptual View
技术概念架构是组织内部实现企业级 Web 服务的技术基础。技术概念架构的高层示意图展示了一组通用层级，这些层级为 Web 服务的构建提供企业级服务能力。这些层级包含所有 Web 服务应用或系统都必需的公共组件。
Figure 5. Conceptual view of technology architecture
示意图的最底层是服务平台（Service Platform），为整套系统提供操作系统、硬件、存储、网络，以及安全可信服务与管理服务。
**服务框架（Service Framework）**承载基于 Web 服务的应用所需的流程、业务逻辑、功能与状态管理，它是完整的企业应用服务器，并针对 Web 服务提供专门支持。
**服务交付（Service Delivery）**包含门户与客户端服务，专注于展现层相关问题与技术，支持各类终端设备。
**服务集成（Service Integration）**实现服务与现有业务系统之间的集成和互操作，涵盖遗留应用、商用软件、数据库以及其他 Web 服务。这通常被称为企业应用集成（EAI）。
最后，**服务创建（Service Creation）**提供设计、开发、组装、管理、部署和测试 Web 服务所需的工具、流程、方法学与架构模式。
关于技术架构的这一概念视图，在《技术架构：概念视图》文档中有更详尽的阐述。
Technology Patterns
技术模式是一种架构级模式，定义特定技术环境下架构设计的最佳实践。企业架构师希望在以下关键领域获取指导与最佳实践，用于本组织的架构建设：
- 安全、身份与可信体系
- 与未来系统及现有运行（遗留）系统的集成和互操作
- 部署、运维与管理
- 用于实现可扩展性与性能目标的分布式技术架构
- 保障可靠性与可用性的技术架构
附录A IEEE对于软件架构的定义
原文参见这里。
Software architecture is the fundamental organization of a software system, expressed through its components, the relationships among those components, and the principles governing their design and evolution. It constitutes the earliest and most consequential set of design decisions in a software project, establishing constraints that later implementation choices must respect. The field emerged as a recognized discipline in the 1990s, as system complexity outgrew the capacity of individual design documents, and has since been formalized through ISO/IEC/IEEE 42010:2011, which provides a standard vocabulary and conceptual framework for describing system and software architectures.
软件架构是软件系统的基本组织，通过其组件、组件之间的关系，以及支配组件设计与演进的原则来表达。它构成软件项目中最早、影响最为深远的一组设计决策，所确立的约束是后续实现方案必须遵守的。随着系统复杂度超出单一设计文档所能承载的范围，该领域在 20 世纪 90 年代发展成为一门公认学科；此后 ISO/IEC/IEEE 42010:2011 对其进行规范化，该标准为描述系统架构与软件架构提供了标准术语集和概念框架。
Architecture differs from detailed design in scope: where detailed design specifies the internals of individual modules, architecture defines the module boundaries, the communication mechanisms between them, and the mapping of functionality to structural elements. A key contribution of the IEEE 1471 standard for software-intensive systems was distinguishing an architecture from its description, recognizing that the same architectural decisions can be documented from multiple viewpoints such as logical, deployment, and process perspectives.
架构与详细设计在作用范围上有所区别：详细设计规定各个模块的内部实现，而架构定义模块边界、模块间的通信机制，以及功能到结构元素的映射关系。IEEE 1471 标准针对软件密集型系统的一项核心贡献，就是区分架构本身 和架构描述；该标准认识到，同一套架构决策可从多个视角（如逻辑视角、部署视角与流程视角）进行文档化表达。