系统设计-提示工程

系统设计与分析的标准框架（Prompt 模板）
版本：v1.0
用途：分析复杂业务系统、进行架构重构、设计新系统

【第 1 步】理解业务本质（40% 时间）

1.1 三个核心问题

请帮我分析以下系统的业务本质：

1. 这个系统的核心价值是什么？

   • 它解决了什么痛点？
   • 如果没有这个系统会怎样？
   • 谁从中受益？

2. 核心业务流程是什么？

   • 用户如何使用它？
   • 数据如何流动？
   • 状态如何变化？

3. 不可违背的业务规则有哪些？

   • 哪些规则是铁律（绝对不能打破）？
   • 哪些约束是业务固有的？
   • 哪些合规要求必须满足？

1.2 输出要求

• 用一句话总结系统的本质
• 画出核心业务流程图（文字描述即可）
• 列出 3-5 条核心业务规则

【第 2 步】识别领域规则（20% 时间）

2.1 从业务推导规则

基于上述业务理解，请帮我识别：

1. 状态转换规则

   • 系统中有哪些关键状态？
   • 状态之间如何流转？
   • 哪些状态不能跳跃/逆转？

2. 数据一致性规则

   • 哪些数据必须精确（如金额）？
   • 哪些关系必须维护（如订单 - 支付）？
   • 哪些操作必须原子性？

3. 不变性约束

   • 哪些条件在任何时候都必须成立？
   • 哪些 invariant 需要保护？

2.2 输出要求

• 画出状态机图（文字描述）
• 列出所有"铁律"及其理由
• 识别出核心的不变性条件

【第 3 步】划分领域边界（20% 时间）

3.1 限界上下文划分

请根据业务规则划分领域边界：

1. 识别核心领域

   • 哪些是核心业务概念？
   • 哪些是支撑业务概念？
   • 哪些是通用业务概念？

2. 划分原则

   • 高内聚：相关的概念放在一起
   • 低耦合：减少跨边界的依赖
   • 单一职责：每个边界职责清晰

3. 边界矩阵

   领域	核心对象	核心规则	状态机

3.2 输出要求

• 画出领域地图（Domain Map）
• 说明每个领域的职责
• 识别领域间的关系（上下游/合作关系）

【第 4 步】设计数据结构（10% 时间）

4.1 从领域到表结构

基于领域划分，请设计数据结构：

1. 表的划分

   • 每个领域需要哪些表？
   • 为什么要这样划分？
   • 表与表之间的关系？

2. 字段设计

   • 核心字段有哪些？
   • 哪些字段用于关联？
   • 哪些字段用于审计？

3. 索引策略

   • 哪些查询是高频的？
   • 需要哪些索引优化？
   • 是否需要复合索引？

4.2 输出要求

• 给出完整的建表 SQL
• 说明每个表的设计理由
• 标注出主键、外键、索引

【第 5 步】选择技术实现（10% 时间）

5.1 技术选型决策

基于以上设计，请帮我选择技术方案：

1. 架构模式

   • MVC / DDD / 微服务 / 事件驱动？
   • 为什么选择这个模式？
   • 权衡考虑是什么？

2. 分层设计

   • 需要哪几个层次？
   • 每层的职责是什么？
   • 层与层如何交互？

3. 关键技术决策

   • 数据库选型及理由
   • 缓存策略及理由
   • 消息队列（如需要）及理由

5.2 输出要求

• 画出架构图（文字描述）
• 说明关键技术选型的理由
• 列出 trade-off 分析

【第 6 步】设计领域模型

6.1 值对象设计

请识别并设计值对象：

1. 识别标准

   • 哪些概念不需要唯一标识？
   • 哪些概念是描述性的？
   • 哪些概念可以不可变？

2. 设计原则

   • 封装验证逻辑
   • 提供丰富行为
   • 保持不可变性

6.2 实体设计

请识别并设计实体：

1. 识别标准

   • 哪些对象需要唯一标识？
   • 哪些对象需要长期追踪？
   • 哪些对象有独立生命周期？

2. 设计原则

   • 封装业务逻辑
   • 保护不变性
   • 提供清晰接口

6.3 聚合根设计

请识别并设计聚合根：

1. 识别标准

   • 哪些实体是根节点？
   • 哪些实体应该被包含？
   • 聚合的边界在哪里？

2. 设计原则

   • 通过工厂方法创建
   • 封装状态转换
   • 发布领域事件

6.4 输出要求

• 列出所有值对象及其职责
• 列出所有实体及其核心行为
• 列出所有聚合根及其不变性

【第 7 步】设计仓储和服务

7.1 仓储接口

请设计仓储接口：

1. 接口定义

   • 需要哪些 CRUD 方法？
   • 需要哪些查询方法？
   • 返回类型如何设计？

2. 设计原则

   • 面向聚合根编程
   • 返回领域对象而非 PO
   • 使用 Optional 处理空值

7.2 应用服务

请设计应用服务：

1. 职责定位

   • 协调多个领域对象
   • 处理事务边界
   • 调用外部服务

2. 方法设计

   • 方法名表达意图
   • 参数简洁明了
   • 返回值有意义

7.3 输出要求

• 给出仓储接口定义
• 给出应用服务接口定义
• 说明两者的职责区别

【第 8 步】实现代码结构

8.1 项目组织

请设计项目结构：

project/  
├── domain/              # 领域层  
│   ├── model/  
│   │   ├── valobj/     # 值对象  
│   │   ├── entity/     # 实体  
│   │   └── aggregate/  # 聚合根  
│   ├── event/          # 领域事件  
│   └── port/           # 端口接口  
├── application/         # 应用层  
│   └── service/        # 应用服务  
├── infrastructure/      # 基础设施层  
│   ├── adapter/        # 适配器实现  
│   ├── dao/            # 数据访问  
│   └── gateway/        # 外部服务  
└── interfaces/          # 接口层  ├── http/           # HTTP 接口  └── listener/       # 事件监听  

8.2 编码规范

• 命名规范（类名、方法名、变量名）
• 注释规范（何时注释、注什么）
• 异常处理规范

【第 9 步】验证和迭代

9.1 设计验证

请用以下问题验证设计：

1. 正确性

   • 数据一致性是否保证？
   • 业务规则是否执行？
   • 边界条件是否处理？

2. 可理解性

   • 新人能否快速理解？
   • 代码是否表达意图？
   • 文档是否充分？

3. 可扩展性

   • 新增功能是否容易？
   • 修改影响范围多大？
   • 是否符合开闭原则？

9.2 识别改进点

• 当前设计的不足之处
• 可能的优化方向
• 技术债务清单

【通用原则】

决策优先级

P0: 正确性 > P1: 可理解性 > P2: 可修改性 > P3: 可测试性 > P4: 性能

设计检查清单

□ 业务规则是否都实现了？
□ 状态转换是否都验证了？
□ 数据一致性是否保证了？
□ 异常处理是否完善了？
□ 日志记录是否充分了？
□ 监控指标是否定义了？

常见陷阱提醒

⚠️ 不要过早优化（先正确，再快）
⚠️ 不要过度设计（简单够用就好）
⚠️ 不要忽视业务（技术为业务服务）
⚠️ 不要一次性完美（迭代式改进）

【使用示例】

场景 1：完整分析

"我有一个电商订单系统，请用系统设计标准框架帮我完整分析一遍"

场景 2：针对性分析

"我在设计订单系统时，纠结于订单和支付是否应该分表，请用框架帮我分析"

场景 3：重构旧系统

"现有系统存在 XX 问题，请用上述框架帮我重构..."

场景 4：技术评审

"请用上述框架评审这个设计方案..."

【快速参考卡片】

五步推导法

1. 理解业务本质（Why）- 40%
2. 识别领域规则（Rules）- 20%
3. 划分领域边界（Boundaries）- 20%
4. 设计数据结构（Data Model）- 10%
5. 选择技术实现（Technology）- 10%

核心问题清单

✓ 这个系统的本质是什么？
✓ 不可违背的规则有哪些？
✓ 领域边界在哪里？
✓ 数据如何组织？
✓ 技术如何选型？

设计原则优先级

P0: 正确性（数据一致、业务规则）
P1: 可理解性（新人 1 小时看懂）
P2: 可修改性（改动影响范围小）
P3: 可测试性（能单元测试）
P4: 性能（在满足前 3 者前提下优化）

---

最后更新：2026-03-28
版本：v1.0