架构原则是什么
架构原则是少数几条可执行的取舍准则，在方案评审时用来判断设计是否合格、例外是否成立。它的作用是把反复争论的问题一次性对齐，例如按业务域解耦、默认复用、数据单一来源、面向失败设计。
基本要求
| 数量 | 常见 5-10 条，可记忆、可执行，超过就没人用 |
|---|---|
| 结构 | 原则陈述 + 理由 + 应用示例 + 例外流程 |
| 治理 | 评审对照原则逐条检查，例外需记录、约定复审时间 |
| 维护 | 随战略与约束变化修订，保留版本与修订原因 |
典型使用场景
- 方案评审时统一判断标准，减少凭个人偏好争论
- 新项目立项：用原则快速排除明显不合规的设计
- 跨团队接口设计：数据归属与复用方式有据可依
- 例外处理：明确谁批、记录在哪里、什么条件下复审
- 新人 onboarding：几条原则比几百页规范更容易记住
原则写法示例
原则写法示例
原则：每类数据有单一权威系统与责任人
理由：避免多副本口径冲突与对账成本
应用：报表从权威系统取数，不直连业务库
例外：走架构评审，约定数据同步方式与校验规则
反例写法：设计要优雅、系统要高可用
问题：无法判断某个方案是否违反，评审时照样各说各话原则四要素
| 要素 | 作用 | 缺失后果 |
|---|---|---|
| 陈述 | 给出可判断的准则 | 无法作为评审依据 |
| 理由 | 解释为什么这么定 | 被质疑时无据可依，容易破例 |
| 应用示例 | 展示在真实场景怎么用 | 理解偏差，执行走样 |
| 例外流程 | 说明何时可以不走原则 | 要么死板阻塞业务，要么形同虚设 |
原则应尽量少而硬：能被一线记住并在评审里真正用上的三五条，比挂在墙上的二十条更有约束力。