应用架构（Application Architecture）

定义与目标

应用架构定义实现业务能力的数据处理与功能组件、系统边界、接口与交互方式，旨在构建可演进、可维护、可集成的应用组合（Application Portfolio）。

应用架构不是简单列系统清单。它要回答每个系统为什么存在、负责哪些业务能力、拥有哪些数据、对外提供什么服务、和其他系统通过什么方式协作。系统越多，应用边界越需要被显式定义。

主要内容

• 应用组合与分层（前台/中台/后台）
• 领域与边界上下文（DDD）
• 应用服务化与API治理（REST/gRPC/Event）
• 集成模式（同步/异步、编排/编舞、消息驱动）
• 非功能性需求：可用性、性能、可维护性、可观测性
• 应用生命周期管理（ALM）与发布策略

关键工件

• 应用地图与系统清单
• 领域模型与上下文映射
• 服务接口规范与契约
• 集成架构与消息模型
• 质量属性场景（QAS）与架构战术

方法与步骤（ADM Phase C-Application）

1. 基线应用架构与能力映射
2. 目标应用蓝图与演进路径
3. 服务化/API策略与网关治理
4. 集成与数据一致性策略
5. 非功能性需求验证（场景/战术）
6. 差距分析与迁移计划

质量属性与战术

• 可用性：冗余、故障隔离、降级与熔断
• 性能：缓存、负载均衡、异步化
• 可修改性：模块化、抽象、契约优先
• 安全性：零信任、最小权限、密钥管理
• 可观测性：日志、追踪、指标、告警

例子：全渠道应用边界

继续以零售数字化为例，应用架构要把不同系统的职责边界讲清楚。

应用	主要职责	不应该承担的职责
商城前台	商品展示、购物车、下单入口、用户交互	不直接维护会员等级、库存主口径和履约规则
会员中心	会员身份、等级、权益、积分、触达记录	不承接订单状态流转和库存扣减
订单中心	订单创建、状态机、支付结果、取消退款、售后协同	不维护商品主数据，不直接计算全局库存
库存中心	可售库存、锁定库存、库存事件、库存同步	不处理会员权益，也不直接负责营销活动
物流履约	发货、配送、签收、门店自提、异常物流	不负责订单交易规则和支付状态

如果商城直接写库存、订单系统自己维护会员等级、门店系统又有独立商品编码，短期能跑，长期会造成接口混乱、数据不一致和重复能力建设。应用架构的价值就是把这些边界前置定义清楚。

同步调用与异步事件

应用协作通常不是单一模式。同步 API 适合需要立即得到结果的查询或校验，例如下单前查询会员权益；异步事件适合跨系统状态传播，例如订单已支付、库存已锁定、包裹已发货。

协作方式	适合场景	风险控制
同步 API	实时查询、强依赖校验、用户请求链路	超时、重试、降级、限流
异步事件	状态通知、最终一致性、削峰解耦	幂等、顺序、补偿、死信处理
批处理	对账、报表、历史迁移、离线分析	数据校验、断点续跑、血缘记录

最佳实践

• 以域和能力为边界进行服务划分
• 契约优先的API设计与治理
• 事件驱动的解耦与最终一致性
• 逐步演进遗留系统，控制耦合与风险

总结

应用架构在业务与技术之间起到承上启下作用。它把业务能力落到系统边界和协作契约上，再把非功能需求传递给技术架构。好的应用架构不是系统越多越好，而是职责清晰、协作稳定、变化可控。