# Enterprise Architecture Governance

## 来源

本规则由企业原始规范整理而来，当前仓库以本文件作为可执行口径，不再依赖 `规范合集/` 目录作为生效范围。

## 规划前置

- 企业内部应用在 `/team-intake`、`/team-plan` 或 ADR 阶段，必须先判断业务评定等级、底线评定等级，并以更高等级作为最终应用等级。
- 需要显式确认是否属于主营业务主链路、是否要求 `7x24`、是否涉及敏感数据/跨境数据/监管风险；无法确认时按更高风险等级处理。
- 方案阶段要先确认所属领域分类和治理模式；如果分委会边界不清晰，默认按“统一规则、统一能力、资产可视可控”的更严口径设计。

## T1-T4 基线

- `T1`：在 `T2` 基础上进一步强调关键资源独占或强隔离，核心中间件、数据库、缓存、注册/配置等要有独立容量与回滚准备。
- `T2`：在 `T3` 基础上强调多实例、集群、高可用与跨机房/跨地域能力，发布与容灾策略不能只靠单点部署。
- `T3`：必须具备限流、熔断、扩缩容、多版本冗余、统一技术栈/运行环境/中间件/能力底座，并完成资产可视可控接入。
- `T4`：可以简化架构复杂度，但不能绕过安全、合规、审计、可回滚这些底线要求。

## 统一架构约束

- 架构设计默认遵循 `IAAS / PAAS / SAAS / BAAS` 的分层思路，下层提供稳定能力，上层只组合和扩展，不重复造底座。
- 默认使用集团认可的 PAAS、能力底座、技术底座和中间件，不私自新增未经评审的自建平台或非稳定版本依赖。
- 涉及前端时，要明确统一框架选型、基础组件库、数据流方案和兼容性基线；涉及后端时，要明确统一运行环境、统一中间件与统一可观测接入。
- 任何偏离集团标准组件或部署方式的方案，都必须通过 ADR 记录原因、替代方案、风险和回退路径。

## 资产可视可控

- 进入开发前至少要能追溯应用等级、ADR、接口契约、代码仓、部署架构图与负责人。
- 进入联调或发布前，`T1-T3` 应用必须补齐 TA/技术架构图、接口文档、部署架构图、监控/日志/告警接入信息。
- 资产文档要和真实部署保持同步；“先上线，后补图”不视为合格交付。
- 企业内部应用的 ADR 与 Release Plan，统一使用模板中的“企业内控补充（按需填写）”区块承载应用等级、技术架构等级、关键组件偏离、资源隔离和资产文档入口。

## 角色要求

- `tech-lead`：判断等级、冲突和偏离是否需要升级仲裁。
- `architect`：把等级要求落到部署、组件、数据、观测和回滚方案里。
- `backend-engineer` / `frontend-engineer`：按统一栈实现，不默认跳过集团底座和公共能力。
- `qa-engineer`：验证等级对应的高可用、观测、隔离和回滚证据是否真实存在。
- `devops-engineer`：把资源隔离、发布窗口、回滚和监控项写进发布方案，而不是口头承诺。