docs(architecture): 添加分布式系统适用边界章节

新增分布式系统适用边界的详细说明，包括：

- 核心原则：代价先验
- 驱动因素：为什么必须分布式
- 主要代价分析
- 不适用场景的原则判断

完善了分布式架构决策的指导原则。

Author: 0xcaffebabe

doc/软件工程/架构/系统设计/分布式/分布式.md

@@ -219,6 +219,41 @@ books: [
 > 分布式系统不是"选择正确方案"，
 > 而是**明确你愿意付出的代价**。
 
+## 适用边界
+
+### 核心原则：代价先验
+
+分布式架构的**本质是代价交换**，而非能力增强。引入分布式之前，必须明确你愿意为之付出的代价。
+
+### 驱动因素：为什么必须分布式
+
+只有以下力量能驱动分布式架构的引入——缺少任何一个，分布式就是过度设计：
+
+| 驱动力 | 本质 |
+|-------|------|
+| **规模压力** | 单机算力/存储/带宽无法承载业务量 |
+| **可用性要求** | 单点故障不可接受，业务中断代价极高 |
+| **独立演进** | 业务领域边界清晰，需并行开发与发布 |
+| **地域分布** | 用户或数据有物理位置约束 |
+
+### 主要代价
+
+分布式系统引入的代价是**不可消除的根本性成本**：
+
+- **延迟**：跨网络调用比进程内调用更高
+- **一致性**：发生网络分区时，强一致性与高可用性不可兼得（CAP 约束）
+- **复杂性**：节点增多导致故障定位、版本管理、运维成本指数增长
+- **组织摩擦**：服务边界需要跨团队协调
+
+### 不适用场景的原则判断
+
+以下场景天然不适合分布式，应优先选择单体：
+
+1. **业务规模未超出单机上限** — 分布式解决的是规模问题，规模未达瓶颈时分布式徒增复杂性
+2. **强一致性事务频繁** — 分布式事务的代价极高，频繁跨服务强一致性场景下分布式是反模式
+3. **团队能力或基础设施不足** — 分布式需要配套的 CI/CD、监控、服务治理能力；能力不足时分布式反而降低可靠性
+4. **业务边界模糊** — 服务拆分依赖清晰的领域边界；边界模糊时的分布式拆分只会制造"分布式单体"
+
 ## 反模式与误区
 
 ### 核心认知：不确定性不可消除