引言

系统架构的完整性取决于业务目标、信息模型、应用职责与运行机制之间的一致性。仅以服务调用关系或技术组件描述系统，难以充分解释业务能力的实现责任、数据的权威来源，以及质量要求的满足方式。

4A 架构从业务架构、数据架构、应用架构和技术架构四个领域组织设计决策，建立从业务需求到系统实现的可追溯关系。其核心价值在于：以业务目标确定设计方向，以数据与应用边界明确责任，以技术机制实现质量要求，并通过验证证据支持架构决策。

4A 架构的定义与适用范围

本文采用以下四个架构域：

业务架构（Business Architecture，BA）：描述业务目标、组织与角色、业务能力、流程和规则。
数据架构（Data Architecture，DA）：描述数据资产的语义、结构、权责、流转和生命周期管理。
应用架构（Application Architecture，AA）：描述应用及逻辑组件的职责、关系与交互契约。
技术架构（Technology Architecture，TA）：描述支撑应用和数据管理的技术能力、运行平台与实现机制。

TOGAF 将业务、数据、应用和技术作为企业架构的重要领域。本文使用“4A”作为这四个领域的简称；后续的关系图、检查项与实施建议用于工程分析，不作为 TOGAF 的规范模板。The Open Group 架构工具介绍

架构域划分表达的是关注范围。Controller、Service、Repository 等代码分层属于应用内部设计；独立部署单元属于实现与运行设计。二者均需要接受架构约束，但与四个架构域之间不存在固定的一一对应关系。

架构域	主要决策范围	关键约束	典型交付物
BA	业务目标、能力范围、流程与规则	业务价值、组织责任、业务政策	能力地图、流程模型、业务术语与规则清单
DA	数据语义、结构、权威来源与生命周期	一致性、质量、时效、访问与保留要求	概念及逻辑模型、数据权责表、数据流与治理规则
AA	能力分配、应用边界、协作机制与契约	业务内聚性、数据责任、变化与交付边界	应用全景图、职责分配表、接口与事件契约
TA	平台能力、运行拓扑与技术机制	性能、可用性、安全、恢复能力与成本	技术决策记录、部署拓扑、容量与恢复方案

四个领域可以描述同一业务对象的不同方面。例如，订单状态在 BA 中体现业务含义及转换规则，在 DA 中体现状态表示与权威记录，在 AA 中体现状态维护责任，在 TA 中体现持久化、并发控制与故障恢复机制。跨域设计的目标是保持这些表达在语义和行为上的一致。

BA：业务目标、能力与规则的结构化表达

业务能力与业务流程

业务架构以业务目标和范围为起点，识别目标所依赖的业务能力、参与角色、执行流程及约束条件。

业务能力描述组织履行特定业务职能的能力；业务流程描述在具体场景下，相关活动、参与者与业务对象之间的执行关系。 能力通常用于组织相对稳定的职责，流程用于表达完成业务结果的行为路径。

例如，退款处理可以作为一项业务能力；退款申请、资格校验、退款执行和结果通知构成某一场景下的流程。流程中的相邻关系不能单独作为应用合并或拆分的依据，还需要结合规则内聚性、数据责任及变化特征进行分析。

业务架构应明确以下内容：

分析内容	设计要求
目标与范围	确定服务对象、价值结果、业务范围及成功标准
能力与责任	识别所需能力，明确业务责任主体及协作关系
流程与例外	定义正常路径、异常路径、人工介入与终止条件
对象与规则	统一术语、状态语义、业务不变量及规则依据

异常路径直接影响后续的一致性和恢复设计。例如，支付结果已确认但订单状态尚未更新时，应明确业务允许的处理时限、对账责任和用户可见状态，再据此确定重试、补偿或人工处置机制。

业务对象、领域模型与数据模型的边界

业务对象用于表达业务概念及其关系；DDD 领域模型进一步组织特定边界内的行为与不变量；数据模型则描述信息的结构、关联与存储约束。三者需要保持语义关联，但不要求采用相同的粒度和结构。

同一业务对象可能对应多个应用内的数据表示。例如，“客户”在销售上下文中可能表示潜在购买主体，在结算上下文中可能表示付款责任主体。是否共享标识、如何建立映射，应以业务语义和使用范围为依据。

ArchiMate 的业务对象与数据对象区分也体现了这种差异：业务概念可以在应用中具有不同的数据表示。The Open Group ArchiMate 101

因此，业务架构应为领域建模和数据设计提供统一的概念基础；具体的聚合、持久化结构与服务边界，需要在后续设计中依据行为和约束确定。

DA：数据语义、权责与生命周期治理

数据架构将业务信息需求转化为可管理的数据资产，覆盖概念、逻辑及必要的物理设计，并明确数据在创建、流转、使用和退出过程中的责任。

静态结构与动态流转的统一设计

设计维度	核心内容
数据语义	统一标识、金额、时间、状态等概念及其适用范围
数据结构	定义实体、关系、约束，以及权威记录与派生视图
数据权责	明确业务负责人、质量责任主体与授权写入应用
数据流转	定义生产者、消费者、同步机制、顺序与时效要求
生命周期	定义创建、修订、版本管理、归档和删除规则
数据保护	定义访问范围、分级、脱敏、审计与保留要求

其中，数据的业务责任与系统写入责任应分别建模。业务责任主体负责语义及质量要求；授权写入应用负责执行更新规则并维护记录。数据库账号权限是责任分配的技术实现之一，不能替代业务层面的权责定义。

数据分发与一致性约束

在采用单一权威写入方的设计中，其他应用可以通过 API、事件或受控同步获取数据。查询、搜索和分析场景可以使用派生副本，但应明确其来源、更新延迟、重建方式和适用范围。

一致性要求应落实为可验证的约束，包括：

需要原子成立的业务不变量及其事务边界。
允许暂时不一致的数据及可接受时间窗口。
重复、乱序、遗漏或失败更新的识别与处理机制。
对账、修复与异常升级的责任主体。

接口调用、事件分发和批量同步分别具有不同的时效、耦合与运维特征。同步方式应由业务时效、访问规模和数据责任共同决定；“最终一致性”也应同时包含收敛条件与异常恢复机制。

AA：应用职责、边界与协作契约

应用架构将业务能力分配到应用或逻辑组件，并通过接口、事件和协作协议组织其交互。应用边界应与业务规则、数据权责及变化边界保持协调。

逻辑职责与部署边界

应用划分至少应评估以下因素：

评估因素	判断依据
业务内聚性	相关行为与规则是否围绕共同目标变化
数据与一致性	业务不变量、写入责任和事务边界能否明确归属
独立演进需求	组件是否具有差异化的发布节奏与契约稳定性要求
运行需求	是否需要独立扩容、故障隔离或资源配置
组织与交付	团队责任、协作成本和运维能力是否支持相应边界

逻辑组件可以在同一进程中实现，也可以形成独立部署单元。独立部署应有明确的演进或运行收益，并评估网络交互、分布式状态和运维复杂度的增量成本。

因此，应用边界的合理性应依据职责、约束和变化特征进行评审，服务数量本身不构成评价依据。

契约与业务不变量

应用交互契约应规定业务含义、输入输出、前置条件、错误语义、幂等、重试和版本兼容策略。事件契约还需明确事实发生的时点、标识及消费者可以依赖的语义。

例如，“取消订单”是受业务规则约束的命令。负责订单能力的应用应验证取消资格并维护状态不变量；调用方通过契约获取行为结果，无需复制内部状态判断。

业务 API 和领域事件应根据协作需求设计，与内部持久化结构保持必要隔离。否则，表结构调整可能被动传播到外部消费者，削弱应用独立演进能力。

TA：质量属性驱动的技术实现

技术架构依据应用交互、数据管理及运行约束，确定平台、存储、网络、中间件和运维机制。技术选型应说明方案对质量属性的贡献、适用条件及成本，而不仅列出组件名称。

将质量要求转化为可度量场景

性能、可用性、安全和可恢复性等要求需要具备明确的适用条件与评价标准。SEI 的质量属性场景方法将需求与刺激、环境、系统响应及响应度量关联，用于澄清架构驱动因素并支持权衡。SEI Quality Attribute Workshop

以下为方法说明所使用的假设性指标，不代表已经完成的容量评估或测试结果：

质量属性	场景与验收条件示例	验证依据
性能	在约定的数据规模、缓存状态和峰值负载下，订单查询 P95 响应时间不超过 300 ms	可复现的负载模型、压测记录与资源指标
可用性	单个应用实例故障后，请求处理在约定时间内恢复，错误率保持在服务目标范围内	故障注入、流量观测与恢复记录
可恢复性	根据业务影响确定 RPO 与 RTO，并验证备份和恢复流程满足目标	恢复演练、数据核对与耗时记录
幂等性	同一业务操作重复提交或超时重试时，不产生重复的业务效果	并发、重复请求及故障恢复测试
访问控制	未获授权的主体无法执行受限操作或读取受限数据，并生成必要审计记录	权限测试与审计验证

RPO（恢复点目标）约束可容忍的数据丢失范围，通常以时间衡量；RTO（恢复时间目标）约束业务恢复所需时间。二者需要由业务影响分析确定，并通过恢复测试验证。

单实例故障演练的结论也有明确适用范围，不能直接外推为跨机房或跨地域容灾能力。质量结论应与测试覆盖的故障模型保持一致。

技术约束的跨域反馈

技术条件会反向影响业务方案。例如，跨地域同步写入的时延、可用性和成本约束，可能要求重新评估数据分布、应用交互或业务完成条件。

安全、可观测性、可运维性与成本同样具有跨域性质。BA 明确业务授权与责任，DA 定义数据保护要求，AA 确定执行边界，TA 提供实现与运行控制。跨域要求应具有统一的责任链和验收口径。

四个架构域的协同机制

图中关系表示设计输入、协同约束与实现支撑，不表示运行时调用顺序或源码依赖。

业务约束向数据与应用设计传递

BA 为 DA 和 AA 提供一致的业务语义及规则。业务流程约束应用行为，业务对象和不变量约束数据表示与更新行为。

例如，“支付完成”应明确表示支付渠道受理、资金到账，还是业务侧已确认结算。该定义应贯穿状态模型、事件语义和接口返回，防止不同应用对同一状态产生不同解释。

数据权责与应用职责相互校验

DA 明确数据的权威来源、更新规则和一致性要求；AA 确定执行这些职责的应用及其交互契约。二者应共同确认状态维护主体、信息分发方式和异常处理责任。

对于多来源数据，设计还需明确权威范围、冲突处理与合并策略。应用划分和数据划分应迭代校验，避免形成职责重叠或无人负责的数据状态。

技术实现与质量目标形成反馈闭环

TA 提供应用运行和数据管理所需的技术机制，同时将平台限制、故障模式和资源成本反馈到其他架构域。对于影响方案成立的关键假设，应在设计早期通过原型、测试或分析取得证据。

四个领域之间具有逻辑上的需求传递关系，但实施过程应支持迭代与反馈。设计完成的判断依据是约束的一致落实，而非文档依次交接。

跨域决策示例：取消订单与退款处理

假设业务要求同一支付操作不得重复扣款，已支付订单的取消流程需要包含退款处置。该示例用于说明跨域映射，不预设服务拆分或中间件方案。

架构域	需要确定的约束	对应设计决策
BA	取消资格、取消完成条件、退款失败后的业务责任	定义状态转换、例外流程与人工处置规则
DA	订单、支付与退款记录的关联及权威范围	定义业务标识、状态语义、写入权责与对账依据
AA	资格判断、退款执行、状态协调的职责分配	定义命令、结果查询、事件及幂等契约
TA	重试、重复消息、超时与节点故障下的行为	确定事务、持久化、可靠投递、监控和恢复机制

若业务允许取消先完成、退款异步处理，则订单取消和退款完成是两个需要分别管理的事实。DA 应表达独立状态，AA 应承担后续推进与结果查询职责，TA 应提供可靠执行和恢复能力。

若业务规定退款成功是取消完成的前置条件，则状态机、对外响应和超时处置均需调整。业务规则的差异会沿数据、应用与技术设计持续传递，无法仅通过替换某个技术组件消除。

该示例表明，架构评审需要验证规则到实现的映射完整性。相同的组件组合并不能证明系统具有相同的业务行为。

架构落地与评审依据

建立需求、决策与证据的追溯链

关键业务目标和规则应能够追溯到数据责任、应用责任、技术措施及验证证据。以下为一种可用于评审的映射方式：

业务目标或规则	数据责任	应用责任	技术措施	验证证据
同一操作不重复扣款	保存操作标识与支付结果	验证幂等并处理结果未知状态	唯一约束、本地事务、渠道幂等或结果查询、对账	重复提交、并发、超时及故障恢复测试
订单状态具有确定的业务解释	维护权威状态及查询副本时效	负责状态推进与对外查询契约	可靠投递、监控、状态核对与修复	延迟、乱序、重复及遗漏事件测试

技术措施应与外部系统的协议能力共同评估。例如，本地唯一约束可以限制重复写入，但不能独立证明跨系统支付操作只产生一次业务效果；还需要分析渠道幂等、结果未知状态及对账恢复路径。

描述现状、目标与过渡架构

架构设计需要覆盖目标状态及其演进过程。职责迁移和数据迁移应明确：

现有能力与目标能力之间的差距。
历史数据迁移、校验和增量同步方式。
过渡期的数据写入权与状态权威来源。
新旧接口及事件的兼容范围和退出条件。
灰度验证、故障回退与责任交接机制。

过渡期同样需要满足业务不变量和运行要求。评审仅覆盖目标拓扑，会遗漏迁移阶段的双写冲突、状态不一致和兼容性风险。

按风险与证据组织验证

验证优先级应依据风险的业务影响、发生可能性及修复成本确定。影响方案成立的关键假设，应在大规模实施之前完成确认。

不同结论需要不同类型的证据：业务规则由责任主体确认；接口和状态约束通过契约及行为测试验证；容量与时延通过负载测试验证；恢复能力通过故障和恢复演练验证。

对于范围有限的项目，可以将四个领域的分析合并到适当规模的设计文档中。文档形式可以精简，但关键决策的依据、责任和验证状态应完整保留。

典型设计偏差

偏差	主要风险	评审重点
以功能清单代替业务架构	业务目标、角色责任与规则缺失	能力与流程能否追溯到业务结果
数据设计仅覆盖表结构	语义、权责、时效与生命周期不明确	权威记录、写入责任及治理规则是否完整
应用边界直接等同于部署单元	职责划分受实现形式主导	边界是否具有业务、数据或独立演进依据
技术方案仅列组件	无法判断质量要求是否得到满足	选型是否对应明确约束和验证证据
跨域设计缺少反馈	成本或可行性问题无法及时反映	关键假设及约束是否持续校验
图示与实现缺少关联	文档逐步偏离接口、数据和部署状态	变更是否同步维护追溯关系与评审记录