@chongyan/autospec 1.0.1 → 1.0.3

package/knowledge/templates/database-design.md

@@ -1,132 +0,0 @@
-# 数据库设计模板
-
-> 规范化数据库设计文档，确保数据模型清晰、一致。
-
-## 使用说明
-
-1. 每个数据库或模块使用独立的 .md 文件
-2. 文件命名：`{数据库名}-{模块名}.md`，如 `order-db.md`
-3. 表结构变更需更新版本历史
-
-## 数据库概述
-
-| 字段 | 值 |
-|------|-----|
-| 数据库名 | {database_name} |
-| 数据库类型 | MySQL / PostgreSQL / MongoDB |
-| 字符集 | utf8mb4 |
-| 排序规则 | utf8mb4_unicode_ci |
-
-## ER 图
-
-```mermaid
-erDiagram
-    USER ||--o{ ORDER : places
-    USER {
-        bigint id PK
-        varchar username
-        varchar email
-        datetime created_at
-    }
-    ORDER ||--|{ ORDER_ITEM : contains
-    ORDER {
-        bigint id PK
-        bigint user_id FK
-        decimal total_amount
-        varchar status
-        datetime created_at
-    }
-    ORDER_ITEM {
-        bigint id PK
-        bigint order_id FK
-        bigint product_id FK
-        int quantity
-        decimal price
-    }
-```
-
-## 表结构
-
-### {表名}
-
-**表说明**：{表的业务含义}
-
-| 字段名 | 类型 | 可空 | 默认值 | 说明 |
-|-------|------|------|-------|------|
-| id | BIGINT | 否 | AUTO_INCREMENT | 主键 |
-| {field} | VARCHAR(255) | 否 | - | {说明} |
-| created_at | DATETIME | 否 | CURRENT_TIMESTAMP | 创建时间 |
-| updated_at | DATETIME | 否 | CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP | 更新时间 |
-
-**索引设计**
-
-| 索引名 | 类型 | 字段 | 说明 |
-|-------|------|------|------|
-| PRIMARY | 主键 | id | 聚簇索引 |
-| idx_{field} | 普通 | {field} | 查询优化 |
-| uk_{field} | 唯一 | {field} | 唯一约束 |
-
-**DDL 语句**
-
-```sql
-CREATE TABLE `{table_name}` (
-  `id` BIGINT NOT NULL AUTO_INCREMENT,
-  `{field}` VARCHAR(255) NOT NULL COMMENT '{说明}',
-  `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
-  `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
-  PRIMARY KEY (`id`),
-  INDEX `idx_{field}` (`{field}`)
-) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='{表说明}';
-```
-
-## 字段命名规范
-
-| 规则 | 示例 |
-|------|------|
-| 主键 | `id` |
-| 外键 | `{referenced_table}_id` |
-| 布尔值 | `is_{action}` / `has_{feature}` |
-| 时间 | `{action}_at` / `{action}_time` |
-| 数量 | `{entity}_count` / `{entity}_num` |
-| 金额 | `{entity}_amount` / `{entity}_fee` |
-
-## 状态枚举
-
-### {状态类型}
-
-| 值 | 名称 | 说明 |
-|-----|------|------|
-| 0 | INIT | 初始状态 |
-| 1 | PROCESSING | 处理中 |
-| 2 | SUCCESS | 成功 |
-| 3 | FAILED | 失败 |
-| -1 | CANCELLED | 已取消 |
-
-## 数据一致性保障
-
-### 事务边界
-
-| 场景 | 事务范围 | 隔离级别 |
-|------|---------|---------|
-| {场景1} | {表列表} | READ COMMITTED |
-| {场景2} | {表列表} | READ COMMITTED |
-
-### 并发控制
-
-| 场景 | 控制方式 | 说明 |
-|------|---------|------|
-| 库存扣减 | 乐观锁 | version 字段 |
-| 余额变更 | 悲观锁 | SELECT FOR UPDATE |
-| 订单创建 | 分布式锁 | Redis Lock |
-
-## 版本历史
-
-| 版本 | 日期 | 修改人 | 修改说明 |
-|-----|------|--------|---------|
-| v1.0 | YYYY-MM-DD | | 初始版本 |
-
----
-
-**维护者**: 后端团队
-**进化分区**: 受控区
-**关联文档**: `design-knowledge/architecture/{name}.md`

package/knowledge/templates/domain-driven-design.md

@@ -1,321 +0,0 @@
-# 领域驱动设计: {项目/系统名}
-
-> **版本**: v1.0
-> **模板来源**: Eric Evans《领域驱动设计》、Vaughn Vernon《实现领域驱动设计》、Microsoft Azure官方指南、DDD Crew最佳实践
-> **适用范围**: 复杂业务系统、核心业务建模、微服务边界划分
-> **生成模式**: 战略设计 → 战术设计 → 实现约束
-
----
-
-## 1. 战略设计
-
-### 1.1 领域识别
-
-> 识别问题空间，划分核心域、支撑域、通用域
-
-| 领域类型 | 领域名称 | 描述 | 业务价值 | 投入建议 |
-|---------|---------|------|---------|---------|
-| 核心域 | | 核心竞争力，必须自研 | | 重点投入 |
-| 支撑域 | | 支撑核心业务，可外包 | | 适度投入 |
-| 通用域 | | 通用能力，可用现成方案 | | 最小投入 |
-
-**核心域识别标准**：
-- 是否是业务核心竞争力？
-- 是否需要定制开发？
-- 是否难以被替代？
-
-### 1.2 限界上下文
-
-> 定义解空间边界，每个上下文内有独立的统一语言
-
-| 上下文名称 | 职责边界 | 包含聚合 | 统一语言关键术语 | 技术栈 |
-|-----------|---------|---------|-----------------|--------|
-| | | | | |
-
-**限界上下文划分原则**：
-- 按业务能力划分（推荐）
-- 按子域划分
-- 边界内语言一致性
-- 边界间松耦合
-
-### 1.3 上下文映射图
-
-```mermaid
-graph LR
-    subgraph 核心域
-        A[上下文A]
-        B[上下文B]
-    end
-
-    subgraph 支撑域
-        C[上下文C]
-    end
-
-    subgraph 通用域
-        D[上下文D]
-    end
-
-    A -->|模式| B
-    A -->|模式| C
-    B -->|模式| D
-```
-
-### 1.4 上下文集成模式
-
-| 上游上下文 | 下游上下文 | 集成模式 | 说明 | 通信方式 |
-|-----------|-----------|---------|------|---------|
-| | | Partnership | 伙伴关系，共同演进 | 同步/异步 |
-| | | Shared Kernel | 共享内核，共享部分模型 | 共享库 |
-| | | Customer/Supplier | 客户-供应商，下游有话语权 | API |
-| | | Conformist | 跟随者，下游适应上游 | API |
-| | | Anticorruption Layer | 防腐层，隔离外部模型 | 适配器 |
-| | | Open Host Service | 开放主机服务，公开API | REST/gRPC |
-| | | Published Language | 发布语言，共享文档 | Schema |
-
-**集成模式选择指南**：
-
-| 场景 | 推荐模式 |
-|------|---------|
-| 同一团队，紧密协作 | Partnership |
-| 共享核心逻辑 | Shared Kernel |
-| 下游有议价权 | Customer/Supplier |
-| 下游无议价权 | Conformist |
-| 外部系统集成 | Anticorruption Layer |
-| 对外提供服务 | Open Host Service |
-
----
-
-## 2. 战术设计
-
-### 2.1 统一语言术语表
-
-> 每个限界上下文有独立的术语表，消除沟通歧义
-
-| 术语 | 英文 | 定义 | 所属上下文 | 代码命名 |
-|-----|------|------|-----------|---------|
-| | | | | |
-
-**术语分类**：
-- 业务实体：订单、用户、商品...
-- 业务动作：下单、支付、发货...
-- 业务状态：待支付、已支付、已取消...
-- 业务规则：限额、时效、条件...
-
-### 2.2 聚合设计
-
-> 聚合是一致性边界，包含实体和值对象
-
-| 聚合名称 | 聚合根 | 实体 | 值对象 | 不变量规则 | 所属上下文 |
-|---------|--------|------|--------|-----------|-----------|
-| | | | | | |
-
-**聚合设计原则**：
-- 小聚合优于大聚合
-- 通过ID引用其他聚合
-- 聚合边界 = 一致性边界 = 事务边界
-- 聚合根是唯一入口
-
-### 2.3 聚合根详情
-
-#### {聚合名称}
-
-**标识**: {聚合根ID字段}
-
-**属性**:
-| 字段名 | 类型 | 说明 | 是否值对象 |
-|-------|------|------|-----------|
-| | | | |
-
-**行为**:
-| 方法名 | 前置条件 | 后置条件 | 领域事件 | 业务规则 |
-|-------|---------|---------|---------|---------|
-| | | | | |
-
-**不变量**:
-- 不变量1：{描述}
-- 不变量2：{描述}
-
-**状态机**:
-```mermaid
-stateDiagram-v2
-    [*] --> 初始状态
-    初始状态 --> 状态A: 事件1
-    状态A --> 状态B: 事件2
-    状态B --> [*]: 事件3
-```
-
-### 2.4 领域服务
-
-> 不属于任何实体/值对象的领域操作
-
-| 服务名称 | 职责 | 操作的聚合 | 领域事件 | 无状态 |
-|---------|------|-----------|---------|--------|
-| | | | | ✅ |
-
-**领域服务识别标准**：
-- 涉及多个聚合的协调
-- 不自然属于任何实体
-- 无状态操作
-
-### 2.5 领域事件
-
-> 领域中发生的业务事实，用于聚合间通信
-
-| 事件名称 | 触发条件 | 携带数据 | 发布方 | 订阅方 | 异步 |
-|---------|---------|---------|--------|--------|------|
-| | | | | | |
-
-**领域事件命名规范**：
-- 过去时：OrderCreated, PaymentCompleted
-- 业务语义：描述发生了什么
-- 不可变：事件一旦发生不可修改
-
-### 2.6 仓储接口
-
-> 聚合的持久化抽象，隔离领域层与基础设施
-
-| 仓储名称 | 对应聚合 | 查询方法 | 持久化要求 |
-|---------|---------|---------|-----------|
-| | | | |
-
-**仓储设计规则**：
-- 只按聚合根ID查询
-- 返回完整的聚合（不返回部分）
-- 集合语义：Add, Remove, Get
-- 不暴露SQL细节
-
----
-
-## 3. 实现约束
-
-### 3.1 聚合边界规则
-
-**强一致性**（聚合内部）：
-- 聚合内部状态变更必须保证强一致性
-- 单个聚合 = 单个事务
-- 聚合根负责维护内部一致性
-
-**最终一致性**（聚合之间）：
-- 聚合之间通过领域事件通信
-- 不允许跨聚合的直接调用
-- 接受最终一致性
-
-**访问规则**：
-- 聚合根是唯一入口
-- 外部不可直接操作内部实体
-- 通过聚合根方法修改内部状态
-
-### 3.2 仓储规则
-
-| 规则 | 说明 | 原因 |
-|------|------|------|
-| 只按ID查询 | 不支持复杂查询 | 保持聚合完整性 |
-| 返回完整聚合 | 不返回部分属性 | 保证不变量 |
-| 持久化原子性 | 整个聚合一起保存 | 保证一致性 |
-| 延迟加载 | 按需加载关联聚合 | 性能优化 |
-
-### 3.3 领域事件规则
-
-| 规则 | 说明 |
-|------|------|
-| 命名规范 | 过去时（OrderCreated, PaymentCompleted） |
-| 不可变 | 事件一旦发生不可修改 |
-| 幂等处理 | 同一事件多次处理结果相同 |
-| 版本控制 | 事件结构变更需版本管理 |
-
----
-
-## 4. 反模式警示
-
-| 反模式 | 症状 | 风险 | 正确做法 |
-|--------|------|------|---------|
-| 贫血模型 | 只有getter/setter，无行为 | 业务逻辑散落，难以维护 | 富领域模型，行为内聚 |
-| 大聚合 | 聚合包含过多实体 | 并发冲突、性能问题 | 小聚合，按一致性边界划分 |
-| 跨聚合直接引用 | 聚合A直接持有聚合B对象 | 破坏聚合边界 | 通过ID引用 |
-| 领域服务滥用 | 服务承载所有逻辑 | 过程式代码，失去DDD价值 | 优先放在聚合根 |
-| 忽略统一语言 | 代码与业务术语不一致 | 沟通成本高，易出错 | 重构命名，保持一致 |
-| 仓储暴露SQL | 仓储返回部分字段 | 破坏聚合完整性 | 返回完整聚合 |
-| 事件丢失 | 事件发布后未持久化 | 数据不一致 | 事件溯源或发件箱模式 |
-
----
-
-## 5. 与AutoSpec流程融合
-
-### 需求阶段 → 战略设计
-- 业务域拆解 → 子领域识别（核心域/支撑域/通用域）
-- 用例分析 → 限界上下文边界识别
-- 业务流程 → 上下文集成关系
-
-### 设计阶段 → 战术设计
-- 系统设计 → 聚合设计、领域模型
-- 接口设计 → 领域服务、仓储接口
-- 数据库设计 → 聚合持久化映射
-
-### 实现阶段
-- 代码结构按聚合组织
-- 领域事件驱动解耦
-- 仓储隔离持久化细节
-
----
-
-## 附录：DDD核心概念速查
-
-### 战略设计概念
-
-| 概念 | 定义 | 关键点 |
-|------|------|--------|
-| 统一语言 Ubiquitous Language | 团队共享的业务术语 | 消除沟通歧义 |
-| 领域 Domain | 问题空间 | 业务问题域 |
-| 子领域 Subdomain | 领域的细分 | 核心域、支撑域、通用域 |
-| 限界上下文 Bounded Context | 解空间边界 | 语言一致性范围 |
-| 上下文映射 Context Map | 上下文间关系 | 集成模式选择 |
-
-### 战术设计概念
-
-| 概念 | 定义 | 关键特征 |
-|------|------|---------|
-| 实体 Entity | 有唯一标识的对象 | ID标识、可变、生命周期 |
-| 值对象 Value Object | 无标识、不可变对象 | 不可变、可替换、相等性 |
-| 聚合 Aggregate | 一致性边界 | 聚合根、事务原子性 |
-| 领域服务 Domain Service | 跨聚合操作 | 无状态、领域概念 |
-| 领域事件 Domain Event | 业务事实 | 过去时、不可变 |
-| 仓储 Repository | 持久化抽象 | 集合语义、按ID查询 |
-| 工厂 Factory | 创建逻辑封装 | 复杂对象创建 |
-
----
-
-## 模板使用说明
-
-### 必填章节
-
-以下章节为必填，缺少则DDD设计不完整：
-
-- [ ] 1.1 领域识别
-- [ ] 1.2 限界上下文
-- [ ] 2.1 统一语言术语表
-- [ ] 2.2 聚合设计
-
-### 可选章节
-
-以下章节根据复杂度选择性填写：
-
-- 1.3 上下文映射图（多上下文时必填）
-- 1.4 上下文集成模式（多上下文时必填）
-- 2.3 聚合根详情（核心聚合必填）
-- 2.4 领域服务（有跨聚合操作时填写）
-- 2.5 领域事件（有事件驱动时填写）
-- 2.6 仓储接口（有持久化时填写）
-
-### 最佳实践
-
-1. **先战略后战术**：先划分限界上下文，再设计聚合
-2. **小步迭代**：从核心域开始，逐步完善
-3. **统一语言优先**：术语不一致时先解决术语问题
-4. **反模式警觉**：定期检查是否陷入反模式
-5. **适度设计**：简单场景不过度设计
-
----
-
-**维护者**: AutoSpec 团队
-**进化分区**: 🟡 受控区
-**关联文档**: `knowledge/guides/domain-driven-design.md`, `knowledge/domain/glossary.md`

package/knowledge/templates/product-proposal.md

@@ -1,201 +0,0 @@
-# Proposal: {需求名称}
-
-> **版本**: v1.0
-> **模板来源**: 业界需求工程最佳实践 / 结构化需求分析方法
-> **适用范围**: 所有需求提案文档
-
----
-
-## 1. 背景与价值
-
-### 1.1 业务背景
-
-{描述业务背景：当前面临的问题、市场机会、用户需求等}
-
-### 1.2 业务价值 (Why)
-
-{描述为什么要做这个需求，预期的业务价值是什么}
-
----
-
-## 2. 目标与范围
-
-### 2.1 目标 (Success Criteria)
-
-{用可衡量的指标描述成功标准，例如：
-- 支持 X 场景
-- 性能提升 Y%
-- 用户体验改善（具体指标）
-}
-
-### 2.2 范围 (包含/不包含)
-
-**包含**:
-- {功能范围 1}
-- {功能范围 2}
-
-**不包含**:
-- {明确排除的范围 1}
-- {明确排除的范围 2}
-
----
-
-## 3. 业务架构设计
-
-### 3.1 总体架构图
-
-```mermaid
-flowchart TB
-    subgraph 功能域 1
-        A[模块 A] --> B[模块 B]
-    end
-
-    subgraph 功能域 2
-        C[模块 C] --> D[模块 D]
-    end
-```
-
-### 3.2 需求用例图
-
-```mermaid
-flowchart TB
-    subgraph 角色 1
-        A[用例 A]
-        B[用例 B]
-    end
-
-    subgraph 角色 2
-        C[用例 C]
-    end
-```
-
-### 3.3 业务域拆解
-
-| 场景类型 | 是否涉及 | 业务域 | 识别依据 |
-|---------|---------|--------|---------|
-| 银行/机构对接 | Y/N | {业务域名称} | {识别依据} |
-| 数据管道 | Y/N | {业务域名称} | {识别依据} |
-| AI/模型 | Y/N | {业务域名称} | {识别依据} |
-
-### 3.4 资金流方案 (涉及资金链路时必须)
-
-```mermaid
-flowchart LR
-    账户 A -->|金额/时间 | 账户 B
-    账户 B -->|金额/时间 | 账户 C
-```
-
-### 3.5 用例业务流程
-
-#### 3.5.1 用例 1: {用例名}
-
-```mermaid
-sequenceDiagram
-    participant U as 用户
-    participant S as 系统
-    participant D as 下游
-
-    U->>S: 1. 请求
-    S->>D: 2. 调用
-    D-->>S: 3. 响应
-    S-->>U: 4. 结果
-```
-
-#### 3.5.2 用例 2: {用例名}
-
-{同上}
-
-### 3.6 跨域接口 (概要)
-
-| 接口名 | 调用方 | 被调用方 | 协议 | 说明 |
-|-------|--------|---------|------|------|
-| {接口 1} | {系统 A} | {系统 B} | HTTP/RPC | {说明} |
-
-### 3.7 数据一致性保障
-
-{描述数据一致性方案：
-- 分布式事务（2PC/SAGA）
-- 中间态 + 定时任务重试
-- 消息队列（RocketMQ）
-}
-
----
-
-## 4. 关键决策
-
-| 决策点 | 选项 | 决策 | 理由 |
-|-------|------|------|------|
-| {决策 1} | 选项 A/B | {决策} | {理由} |
-
----
-
-## 5. 风险与缓解
-
-| 风险项 | 影响 | 概率 | 缓解措施 |
-|-------|------|------|---------|
-| {风险 1} | 高/中/低 | 高/中/低 | {措施} |
-
----
-
-## 6. 非目标与约束
-
-### 6.1 非目标
-
-{明确说明本次需求不包含的内容}
-
-### 6.2 知识库缺失识别
-
-| 缺失项 | 影响 | 补充计划 |
-|-------|------|---------|
-| {缺失 1} | {影响} | {计划} |
-
----
-
-## 7. Open Questions
-
-| 问题 | 提出人 | 日期 | 状态 | 决议 |
-|------|--------|------|------|------|
-| {问题 1} | {人名} | {日期} | Open/Closed | {决议} |
-
----
-
-## 8. 参考资料
-
-| 类型 | 标题 | 链接 |
-|------|------|------|
-| 需求文档 | {标题} | {链接} |
-| 设计文档 | {标题} | {链接} |
-| 接口文档 | {标题} | {链接} |
-
----
-
-## 模板使用说明
-
-### 必填章节
-
-以下章节为必填，缺少则提案不完整：
-
-- [ ] 1.1 业务背景
-- [ ] 1.2 业务价值
-- [ ] 2.1 目标
-- [ ] 2.2 范围
-- [ ] 3.2 需求用例图
-- [ ] 3.5 用例业务流程
-
-### 可选章节
-
-以下章节根据需求复杂度选择性填写：
-
-- 3.1 总体架构图（复杂系统需要）
-- 3.3 业务域拆解（涉及多业务域需要）
-- 3.4 资金流方案（涉及资金操作必须）
-- 3.6 跨域接口（涉及跨系统调用需要）
-- 3.7 数据一致性保障（涉及跨系统数据需要）
-
-### 最佳实践
-
-1. **用例原子化**: 每个用例应该是原子的，不可再拆分
-2. **流程图优先**: 能用图表达的不用文字
-3. **明确边界**: 清晰定义包含和不包含的范围
-4. **关键决策记录**: 记录重要技术选型和方案取舍
-5. **风险前置**: 提前识别风险并制定缓解措施