综合项目架构蓝图生成器

配置变量

${PROJECT_TYPE=”自动检测|.NET|Java|React|Angular|Python|Node.js|Flutter|其他”}
${ARCHITECTURE_PATTERN=”自动检测|整洁架构|微服务|分层架构|MVVM|MVC|六边形架构|事件驱动|无服务器|单体架构|其他”}
${DIAGRAM_TYPE=”C4|UML|流程图|组件图|无”}
${DETAIL_LEVEL=”高级|详细|全面|可实施”}
${INCLUDES_CODE_EXAMPLES=true|false}
${INCLUDES_IMPLEMENTATION_PATTERNS=true|false}
${INCLUDES_DECISION_RECORDS=true|false}
${FOCUS_ON_EXTENSIBILITY=true|false}

生成的提示词

“创建一个全面的‘Project_Architecture_Blueprint.md’文档，该文档透彻分析代码库中的架构模式，作为维护架构一致性的权威参考。请使用以下方法：

1. 架构检测与分析

• ${PROJECT_TYPE == “自动检测” ? “通过检查以下内容来分析项目结构，识别所有使用的技术栈和框架：
  • 项目和配置文件
  • 包依赖关系和导入语句
  • 特定于框架的模式和约定
  • 构建和部署配置” : “重点关注 ${PROJECT_TYPE} 特定模式和惯例”}
• ${ARCHITECTURE_PATTERN == “自动检测” ? “通过分析以下内容来确定架构模式：
  • 文件夹组织和命名空间
  • 依赖流向和组件边界
  • 接口隔离和抽象模式
  • 组件间的通信机制” : “记录 ${ARCHITECTURE_PATTERN} 架构是如何实现的”}

2. 架构概览

• 清晰、简洁地解释整体架构方法
• 记录架构选择中体现的指导原则
• 识别架构边界及其如何被强制执行
• 注意任何混合架构模式或对标准模式的调整

3. 架构可视化

${DIAGRAM_TYPE != “无” ? `创建多抽象层级的 ${DIAGRAM_TYPE} 图表：

• 显示主要子系统的高级架构概览
• 显示关系和依赖关系的组件交互图
• 显示信息如何在系统中流动的数据流图
• 确保图表准确反映实际实现，而非理论模式` : “根据实际代码依赖关系描述组件关系，提供清晰的文本说明，内容包括：
• 子系统组织和边界
• 依赖方向和组件交互
• 数据流和流程顺序”}

4. 核心架构组件

对于在代码库中发现的每个架构组件：

• 目的与职责：
  • 在架构中的主要功能
  • 解决的业务领域或技术关注点
  • 边界和范围限制
• 内部结构：
  • 组件内类/模块的组织
  • 关键抽象及其实现
  • 使用的设计模式
• 交互模式：
  • 组件如何与其他组件通信
  • 暴露和消费的接口
  • 依赖注入模式
  • 事件发布/订阅机制
• 演化模式：
  • 组件如何被扩展
  • 变化点和插件机制
  • 配置和定制方法

5. 架构层次与依赖关系

• 映射代码库中实现的层次结构
• 记录各层之间的依赖规则
• 识别实现层分离的抽象机制
• 注意任何循环依赖或层次违规
• 记录用于维持分离的依赖注入模式

6. 数据架构

• 记录领域模型结构和组织
• 映射实体关系和聚合模式
• 识别数据访问模式（仓库、数据映射器等）
• 记录数据转换和映射方法
• 注意缓存策略和实现
• 记录数据验证模式

7. 横切关注点实现

记录横切关注点的实现模式：

• 身份验证与授权：
  • 安全模型实现
  • 权限强制执行模式
  • 身份管理方法
  • 安全边界模式
• 错误处理与弹性：
  • 异常处理模式
  • 重试和断路器实现
  • 降级和优雅降级策略
  • 错误报告和监控方法
• 日志记录与监控：
  • 仪表化模式
  • 可观测性实现
  • 诊断信息流
  • 性能监控方法
• 验证：
  • 输入验证策略
  • 业务规则验证实现
  • 验证职责分配
  • 错误报告模式
• 配置管理：
  • 配置源模式
  • 环境特定配置策略
  • 机密管理方法
  • 功能标志实现

8. 服务通信模式

• 记录服务边界定义
• 识别通信协议和格式
• 映射同步与异步通信模式
• 记录 API 版本控制策略
• 识别服务发现机制
• 注意服务通信中的弹性模式

9. 技术特定架构模式

${PROJECT_TYPE == “自动检测” ? “对于每个检测到的技术栈，记录特定的架构模式：” : 记录 ${PROJECT_TYPE} 特定的架构模式：}

${(PROJECT_TYPE == “.NET” || PROJECT_TYPE == “自动检测”) ?
“#### .NET 架构模式（如果检测到）

• 主机和应用模型实现
• 中间件管道组织
• 框架服务集成模式
• ORM 和数据访问方法
• API 实现模式（控制器、最小 API 等）
• 依赖注入容器配置” : “”}

${(PROJECT_TYPE == “Java” || PROJECT_TYPE == “自动检测”) ?
“#### Java 架构模式（如果检测到）

• 应用容器和启动过程
• 依赖注入框架使用（Spring、CDI 等）
• AOP 实现模式
• 事务边界管理
• ORM 配置和使用模式
• 服务实现模式” : “”}

${(PROJECT_TYPE == “React” || PROJECT_TYPE == “自动检测”) ?
“#### React 架构模式（如果检测到）

• 组件组合和复用策略
• 状态管理架构
• 副作用处理模式
• 路由和导航方法
• 数据获取和缓存模式
• 渲染优化策略” : “”}

${(PROJECT_TYPE == “Angular” || PROJECT_TYPE == “自动检测”) ?
“#### Angular 架构模式（如果检测到）

• 模块组织策略
• 组件层次结构设计
• 服务和依赖注入模式
• 状态管理方法
• 响应式编程模式
• 路由守卫实现” : “”}

${(PROJECT_TYPE == “Python” || PROJECT_TYPE == “自动检测”) ?
“#### Python 架构模式（如果检测到）

• 模块组织方法
• 依赖管理策略
• OOP 与函数式实现模式
• 框架集成模式
• 异步编程方法” : “”}

10. 实现模式

${INCLUDES_IMPLEMENTATION_PATTERNS ?
“记录关键架构组件的具体实现模式：

• 接口设计模式：
  • 接口隔离方法
  • 抽象层级决策
  • 泛型与特定接口模式
  • 默认实现模式
• 服务实现模式：
  • 服务生命周期管理
  • 服务组合模式
  • 操作实现模板
  • 服务内的错误处理
• 仓库实现模式：
  • 查询模式实现
  • 事务管理
  • 并发处理
  • 批量操作模式
• 控制器/API 实现模式：
  • 请求处理模式
  • 响应格式化方法
  • 参数验证
  • API 版本控制实现
• 领域模型实现：
  • 实体实现模式
  • 值对象模式
  • 领域事件实现
  • 业务规则执行” : “提及详细的实现模式因代码库而异。”}

11. 测试架构

• 记录与架构一致的测试策略
• 识别测试边界模式（单元、集成、系统）
• 映射测试替身和模拟方法
• 记录测试数据策略
• 注意测试工具和框架的集成

12. 部署架构

• 从配置中推导并记录部署拓扑
• 识别特定于环境的架构适配
• 映射运行时依赖解析模式
• 记录跨环境的配置管理
• 识别容器化和编排方法
• 注意云服务集成模式

13. 扩展与演化模式

${FOCUS_ON_EXTENSIBILITY ?
“提供扩展架构的详细指南：

• 功能添加模式：
  • 如何在保持架构完整性的同时添加新功能
  • 按类型放置新组件的位置
  • 依赖引入指南
  • 配置扩展模式
• 修改模式：
  • 如何安全修改现有组件
  • 保持向后兼容性的策略
  • 弃用模式
  • 迁移方法
• 集成模式：
  • 如何集成新的外部系统
  • 适配器实现模式
  • 防腐层模式
  • 服务外观实现” : “记录架构中的关键扩展点。”}

${INCLUDES_CODE_EXAMPLES ?
“### 14. 架构模式示例
提取代表性的代码示例，说明关键架构模式：

• 层分离示例：
  • 接口定义与实现分离
  • 跨层通信模式
  • 依赖注入示例
• 组件通信示例：
  • 服务调用模式
  • 事件发布与处理
  • 消息传递实现
• 扩展点示例：
  • 插件注册与发现
  • 扩展接口实现
  • 配置驱动扩展模式

每个示例应包含足够的上下文以清晰展示模式，但保持示例简洁并聚焦于架构概念。” : “”}

${INCLUDES_DECISION_RECORDS ?
“### 15. 架构决策记录
记录代码库中体现的关键架构决策：

• 架构风格决策：
  • 为何选择当前的架构模式
  • 考虑过的替代方案（基于代码演变）
  • 影响决策的约束条件
• 技术选型决策：
  • 关键技术选择及其架构影响
  • 框架选择理由
  • 自定义与现成组件的决策
• 实现方法决策：
  • 选择的特定实现模式
  • 标准模式适配
  • 性能与可维护性权衡

对于每个决策，注明：

• 促成该决策的背景
• 做决策时考虑的因素
• 由此产生的结果（积极和消极）
• 引入的未来灵活性或限制” : “”}

${INCLUDES_DECISION_RECORDS ? “16” : INCLUDES_CODE_EXAMPLES ? “15” : “14”}. 架构治理

• 记录如何维护架构一致性
• 识别架构合规性的自动化检查
• 注意代码库中体现的架构评审流程
• 记录架构文档编写实践

${INCLUDES_DECISION_RECORDS ? “17” : INCLUDES_CODE_EXAMPLES ? “16” : “15”}. 新开发蓝图

为实施新功能创建清晰的架构指南：

• 开发工作流程：
  • 不同类型功能的起点
  • 组件创建顺序
  • 与现有架构的集成步骤
  • 按架构层划分的测试方法
• 实现模板：
  • 关键架构组件的基类/接口模板
  • 新组件的标准文件组织
  • 依赖声明模式
  • 文档要求
• 常见陷阱：
  • 应避免的架构违规
  • 常见架构错误
  • 性能考量
  • 测试盲点

包含关于此蓝图生成时间的信息，以及随着架构发展保持其更新的建议。”