本文为“如何画架构图”系列的第三篇文章，前两篇文章如下：
什么是应用架构
ISO/IEC/IEEE 42010 国际标准中只定义了架构这个术语，应用架构被看作架构的一个特定视角。
在TOGAF 9中，应用架构的定义为：
A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
一份蓝图，用于描述待部署的各个应用系统、系统间交互关系，以及它们与组织核心业务流程之间的关联。
在TOGAF 10中，应用架构的定义为：
A description of the structure and interaction of the applications that provide key business capabilities and manage the data assets.
对提供关键业务能力、管理数据资产的各应用系统的结构及其交互关系的描述。
这两个定义，其实都强调了应用及交互关系，及与关键业务能力的对应关系。
应用架构图的目的
应用架构图用于描述系统的应用组成、应用职责、功能划分以及应用之间的协作关系，建立清晰的应用逻辑结构。
它主要帮助架构师和开发团队回答：系统需要建设哪些应用？每个应用负责什么？应用如何复用公共能力？应用之间如何协作？哪些能力属于本系统，哪些由外部系统提供？
具体目的包括：
- 明确应用职责与边界： 避免职责重叠、功能遗漏和应用之间的边界不清。
- 组织应用功能： 展示应用内部的主要模块及其逻辑归属。
- 识别共享能力： 发现可被多个应用复用的公共业务服务和共享能力。
- 梳理应用依赖： 明确应用之间的调用、依赖和协作关系。
- 指导应用建设与演进： 支持系统拆分、模块化设计、服务化改造和应用整合。
应用架构图框架
应用架构图应包含的主要内容如下：
| 主要内容 | 应表达的信息 |
|---|---|
| 用户与访问渠道 | 用户类型、业务渠道。如Web、移动 App、业务终端等 |
| 核心业务应用 | 主要应用、应用职责及其内部应用模块 |
| 共享应用与公共业务能力 | 公共业务能力、共享数据服务、公共分析能力等 |
| 应用集成与接口 | 接口与服务集成、数据集成、流程集成 |
| 外部系统 | 与本系统交互的外部业务系统和通用技术平台 |
| 应用关系 | 应用之间的调用、依赖、共享能力使用及主要协作关系 |
| 应用边界 | 应用的职责范围、逻辑归属，以及必要的系统内外边界 |
由此形成应用架构图框架，建议包括5部分，分别是用户与访问层、核心业务应用层、共享应用与公共业务能力层、应用集成与接口层和外部系统。
应用架构图详解
将应用架构图框架细化，就得到下图。其中A1和A2层是基于电信业务进行绘制的。
A1 用户与访问层
用户与访问层用于描述系统的用户群体及其访问渠道，展示不同类型的用户如何通过相应的业务渠道与系统进行交互。该层重点体现用户类型、访问入口及渠道形态，为理解系统的服务对象和使用方式提供依据。
其中用户是指使用系统的人员或组织，包括外部客户、企业员工、管理人员、运维人员及其他授权用户等。根据业务场景，可进一步划分用户角色或用户类别。
常见的业务访问渠道如下表：
| 业务访问渠道 | 具体描述 |
|---|---|
| Web 访问渠道 | 用户通过浏览器访问系统的方式，包括企业门户、业务网站、管理后台及其他 Web 应用入口。 |
| 移动访问渠道 | 用户通过手机 App、移动 Web、企业微信或其他移动端应用访问系统的方式，体现移动端的服务入口。 |
| 业务终端渠道 | 用户通过特定业务终端与系统交互的方式，例如自助服务终端、售票窗口终端、柜面终端及其他专用设备。 |
| 系统对接渠道 | 其他系统通过 API、服务接口或其他系统间通信方式访问本系统的业务能力。若图中已将系统间集成统一放在应用集成与接口层，也可以不在本层重复展开。 |
在温昱《业务架构•应用架构•数据架构实战》一书第3.11节，看到另一种业务渠道的画法：即将渠道横向放在中间，用户按内外分别放在上下部分。例如渠道为补票终端和客服电话，则乘客放在上方，下方分别放列车长和客服中心。
A2 核心业务应用层
核心业务应用层用于展示构成系统主体的业务应用及其内部模块，是应用架构图的核心部分。该层以应用为组织单元，按照业务职责划分应用边界，并通过应用模块进一步展示各应用内部的主要功能组成，体现系统的业务功能布局和应用结构。
回顾前面应用架构的定义：
对提供关键业务能力、管理数据资产的各应用系统的结构及其交互关系的描述。
“结构”即以应用为组织单元，内部列出应模块；“关键”表示只需列出主要的应用和应用模块。在架构图中，比较不好处理的是“交互关系”。
在绘制应用交互关系时，可参考如下的应用API调用关系图。不过如果要将此图融入到架构图中，可能存在两个问题。首先，大型系统的API调用关系会更复杂，很容易形成密密麻麻的“蜘蛛网”；其次，尽管API调用是最主要的应用交互方式，但应用之间还可以通过消息与事件异步交互，或通过数据和文件进行数据层的交互。
因此，为保证架构图的可读性，可以只画一些核心的交互关系，如利益相关方关注的交互关系。不影响架构理解的关系，都可以去掉。详细的多个应用之间的完整调用关系，可以放到其他的图表中描述，如接口目录，应用依赖矩阵等。如果已经梳理好应用开放API列表和API调用列表，利用AI工具，基于这些表格再生成图片也非常方便，后续会有专门的文章讨论。
A3 共享应用与公共业务能力层
共享应用与公共业务能力层用于展示由多个核心业务应用共同使用的业务能力和公共支撑能力，体现跨应用的能力复用、统一服务和共享数据利用。该层既包括可供多个应用调用的公共业务能力，也包括共享数据管理、数据分析等数据相关能力，以减少重复建设并提升应用之间的一致性。
建议将本层划分为两个主要部分，即公共业务能力和共享数据与分析能力。
以下是一些常见的公共服务能力示例：
| 组成部分 | 具体描述 | 示例 |
|---|---|---|
| 公共业务规则与处理能力 | 为多个业务应用提供统一的业务规则、计算逻辑或处理能力，确保相关业务处理的一致性。 | 统一计费、价格计算、规则校验 |
| 公共业务服务 | 提供跨应用复用的业务服务，避免多个应用重复实现相同的业务功能。 | 统一客户服务、统一订单查询、统一通知服务 |
| 公共身份与权限能力 | 为多个应用提供统一的身份识别、认证授权及权限管理能力。 | 单点登录、统一认证、统一权限服务 |
| 公共流程与任务能力 | 为多个应用提供可复用的任务处理、流程执行或任务调度能力。 | 审批流程、任务管理、流程规则服务 |
| 公共消息与通知能力 | 提供统一的消息发送、通知分发和消息模板等能力。 | 短信通知、邮件通知、站内消息 |
以下是一些常见的共享数据与分析能力示例：
| 组成部分 | 具体描述 | 示例 |
|---|---|---|
| 共享数据服务 | 向多个业务应用提供统一的数据查询、访问和共享能力，降低应用之间的数据耦合。 | 客户信息查询、组织机构查询、基础数据服务 |
| 主数据与基础数据管理 | 对跨应用共享的核心业务对象及基础信息进行统一管理，维护关键数据的一致性。 | 客户主数据、产品主数据、组织机构数据 |
| 共享数据处理能力 | 为多个应用提供通用的数据加工、转换、汇总和处理能力。 | 数据清洗、公共数据转换、跨应用数据汇总 |
| 数据分析与指标服务 | 提供公共分析模型、业务指标计算及分析结果查询能力，支持不同应用开展业务分析。 | 经营指标、统一报表、业务分析服务 |
| 数据资产与元数据服务 | 提供共享数据的目录、定义、口径及相关元数据管理能力，帮助应用理解和正确使用数据。 | 数据目录、指标口径管理、数据血缘查询 |
上述示例并不意味着所有企业系统都必须建设这些能力。是否纳入本层，应根据实际的共享需求、业务边界和架构设计决定。另外，并非所有共享能力都必须放在一个独立的物理平台中。这里强调的是逻辑上的共享职责，实际部署可以集中，也可以分散在多处。
A4 应用集成与接口层
应用集成与接口层用于描述核心业务应用、共享能力以及外部系统之间的交互和协作机制，重点展示服务调用、数据交换和业务流程协同等集成方式。该层明确应用之间如何建立联系、传递信息和协同处理业务，是连接各应用架构组成部分的重要枢纽。
应用集成的主要方式可以分为三类：
- 接口与服务集成：这是最主要的应用集成方式，关注的是应用之间的功能交互和服务调用，如REST API，API 网关、接口目录等。
- 数据集成：强调的是数据如何在不同应用或数据平台之间流动。它可以通过数据库复制、文件交换、消息传递或 API 等技术实现。
- 流程集成：关注的是多个应用如何共同完成一个跨应用业务过程，而不是单个应用内部的程序执行流程。如跨应用业务流程编排，流程状态与任务协调，业务流程规则与路由，长事务与补偿机制等。
三类集成可以作为该层中的三个子区域，但它们并不一定对应三个相互独立的物理平台。例如，消息队列既可以承担消息集成，也可以承载数据交换或事件驱动的流程协作。
另外，接口与服务集成、数据集成和流程集成在实际实现中可能相互交叉。在真实项目中，他们并不是三道互斥的工序，而是围绕同一个业务目标、在同一套系统间同时发生、互为前提、彼此嵌入的。架构图应按照主要职责进行归类，而不必强行将每种技术划入唯一类别。
A5 外部系统
外部系统用于展示处于本系统应用架构边界之外、但与本系统存在业务协作、数据交互或技术支撑关系的系统和平台。该部分重点体现本系统依赖的外部能力、与其他业务系统的协作关系，以及系统之间的职责边界。
建议将外部系统划分为两个主要类别，即通用技术平台和外部业务系统。
以下为通用技术平台的一些示例：
| 组成部分 | 具体描述 | 示例 |
|---|---|---|
| 统一身份与安全平台 | 为多个系统提供统一的身份认证、授权、访问控制或安全管理能力。 | 企业统一身份认证平台、统一安全管理平台 |
| 企业集成与消息平台 | 为多个系统提供通用的消息传递、接口接入或集成支撑能力。 | 企业级消息平台、共享集成平台 |
| 企业数据平台 | 为多个系统提供统一的数据存储、共享、分析或数据治理能力。 | 企业数据平台、数据仓库、主数据平台 |
| 通用业务支撑平台 | 为多个系统提供组织、人员、通知、电子签章等公共支撑能力。 | 企业组织平台、电子签章平台、统一通知平台 |
| 外部云与 AI 服务平台 | 为本系统提供外部云资源、模型服务或其他通用技术能力。 | 云服务平台、外部大模型服务平台 |
这里有一个重要的边界判断：通用技术平台是否属于外部系统，取决于它是否处于当前系统的架构边界之外，而不是取决于它的技术属性。
例如，某企业的统一消息平台由企业级部门统一建设、由多个系统共同使用，那么它可以作为外部系统展示；如果消息服务是当前系统内部建设的组成部分，则更适合在共享应用与公共业务能力层或相应的技术架构中体现。
以下为通用技术平台的一些示例，此处假设我是一个电商交易系统：
| 组成部分 | 具体描述 | 示例 |
|---|---|---|
| 上游业务系统 | 向本系统提供业务数据、业务请求或前置处理结果的外部系统。 | 客户管理系统、商品管理系统 |
| 下游业务系统 | 接收本系统输出的数据、业务请求或处理结果的外部系统。 | 财务系统、报表系统、下游履约系统 |
| 横向协作系统 | 与本系统在业务流程中相互协作、交换数据或共同完成业务活动的外部系统。 | 支付系统、物流系统、税务系统 |
| 外部监管与公共服务系统 | 由外部机构建设，为本系统提供监管、核验、公共数据或其他公共服务的系统。 | 监管平台、公共信息核验平台 |
| 第三方业务服务系统 | 由外部服务提供方运营、为本系统提供特定业务服务的系统。 | 第三方支付平台、短信服务商业务平台 |
好了，以上就是画应用架构图的框架和思路，希望对您能有所启发。在具体操作时，可以根据自己的实际情况进行调整，例如系统规模不大时，可将共享应用与公共业务能力层合并到核心业务应用层；或者采用更贴合自身行业与业务上下文的术语来表述。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/stevensxiao/article/details/170798721
