Bp Architecture Design

架构设计

> 使用场景：workflow-system-design skill 在讨论 spec.md 4.1 方案概览 时加载本 skill。

第一性原理

> 架构设计的本质：在约束条件下，选择最优的 trade-off 来满足业务目标。

---

设计前：回顾 spec.md 前三节

在提出架构方案前，确保已理解：

| spec.md 章节 | 要回答的问题 | |-------------|-------------| | 1. 背景 | 要解决什么问题？现状是怎样的？ | | 2. 目标 & 非目标 | 成功的标准是什么？什么不做？ | | 3.1 功能性需求 | 系统需要具备哪些能力？ | | 3.2 非功能性需求 | 性能、兼容性、可维护性约束？ |

> 如果非功能性需求可以量化，尽量量化（如 p99 延迟 数据决策决定正确性和运维复杂度。

| 决策点 | 需要明确 | |--------|----------| | 数据所有权 | 哪个模块是这份数据的 source of truth？ | | 一致性模型 | 强一致 vs 最终一致？ | | Schema 演进 | 向前/向后兼容？回滚方案？ |

---

接口设计

> 架构层关注接口原则，详细设计参见 bp-component-design 的 4.2.2 节。

| 原则 | 说明 | |------|------| | 最小化 | 只暴露必要的接口 | | 不泄露内部 | 使用专用 DTO | | 版本兼容 | 接口变更需考虑向后兼容 |

---

与其他 Skill 协同

| 场景 | 加载 Skill | |------|-----------| | 涉及网络通信、多节点、一致性、故障恢复 | bp-distributed-systems | | 涉及类/接口详细设计 | bp-component-design（4.2 节使用） |

---

4.1 方案概览 Checklist

在 spec.md 4.1 节，确认以下内容已讨论：

• [ ] 整体思路：用 1-2 句话描述方案核心
• [ ] 模块划分：涉及哪些模块？边界在哪？
• [ ] 依赖方向：模块间的依赖关系
• [ ] 数据流：数据如何流转？
• [ ] 关键 trade-off：为什么这样设计？牺牲了什么？

---

反模式

| 反模式 | 改进 | |--------|------| | 循环依赖 (A→B→C→A) | 引入接口打破循环 | | 边界模糊（多模块修改同一份数据） | 明确数据所有权 | | 过度抽象 | 简单优先，按需抽象 | | Big Ball of Mud | 逐步引入边界 |

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: davidYichengWei
• Source: davidYichengWei/agentic-engineering-framework
• License: MIT

Install and usage instructions live in the source repository linked above.