brainstorming-laravel

将 Laravel 创意构思成设计方案

概述

通过自然的协作式对话，帮助将 Laravel 功能创意转化为完整的设计方案和规格说明，重点关注 Laravel 最佳实践和生态系统模式。

首先了解当前 Laravel 项目的背景，然后每次提出一个问题，逐步完善创意。了解要构建的内容后，分成若干小节呈现设计方案（每节 200-300 字），并在每节结束后确认目前看来是否合适。

流程

了解创意：

• 首先查看当前 Laravel 项目的状态（路由、模型、迁移、近期提交）
• 每次提出一个问题，逐步完善创意
• 尽可能优先使用选择题，但也可以使用开放式问题
• 每条消息只问一个问题——如果某个主题需要进一步探讨，就将其拆分为多个问题
• 重点了解目的、Laravel 模式、约束条件和成功标准

示例问题：

• “这应该作为队列任务执行，还是同步运行？”
• “要采用哪种身份验证方式：Sanctum、Passport，还是自定义方案？”
• “是否需要通过广播实现实时更新？”
• “应该使用 Eloquent 事件，还是显式调用服务？”

探索方案：

• 提出 2-3 种不同的 Laravel 方案，并说明各自的权衡
• 以对话方式介绍选项，并给出你的建议和理由
• 先给出推荐方案，再解释原因

示例：

For the notification system, I see three approaches:

1. Laravel Notifications with database channel (recommended)
   - Built-in, follows Laravel conventions
   - Easy to add email/Slack later
   - Simple to mark as read
   Trade-off: Less flexible for complex notification logic

2. Custom Event/Listener system
   - Maximum flexibility
   - Can add complex rules
   Trade-off: More code to maintain

3. Third-party package (like Laravel Echo)
   - Real-time out of the box
   Trade-off: External dependency, overkill if not needed

I'd recommend #1 for most cases - start simple, Laravel's notification system is excellent and you can always extend it later if needed.

Which approach feels right for your use case?

呈现设计方案：

• 确认已了解要构建的内容后，呈现设计方案
• 将内容拆分为每节 200-300 字的小节
• 每节结束后询问目前看来是否合适
• 涵盖：数据库架构、模型与关系、路由与控制器、服务/操作、队列/事件、API 资源、验证、测试
• 如果有不明白的地方，随时回头澄清

Laravel 专属设计部分

1. 数据库架构

First, let's look at the database design:

We'll need three tables:
1. `posts` - title, slug, content, status, published_at
2. `tags` - name, slug
3. `post_tag` - pivot table for many-to-many

The posts table will have a foreign key to users, indexed on status and published_at for common queries. We'll use an enum for status (draft, published, archived) to keep it clean.

Does this schema structure make sense for what we're building?

2. 模型与关系

For the models, we'll have:

Post model with:
- belongsTo relationship to User
- belongsToMany relationship to Tag
- Scopes: published(), draft(), recent()
- Casts: published_at as datetime, metadata as array
- Factory for testing

Tag model with:
- belongsToMany relationship to Post
- Slug auto-generation on save

Should we add soft deletes to posts, or will hard deletes work?

3. API 设计

For the API endpoints, following RESTful conventions:

GET    /api/posts           - List posts (paginated)
POST   /api/posts           - Create post
GET    /api/posts/{post}    - Show post
PUT    /api/posts/{post}    - Update post
DELETE /api/posts/{post}    - Delete post

Authentication via Sanctum, rate limited to 60 requests/minute.
API resources will transform the output, hiding sensitive data.

Does this API structure cover your needs?

4. 业务逻辑

The posting workflow:

When a post is published:
1. PostService validates the post is ready (has title, content)
2. Sets published_at timestamp
3. Dispatches NotifySubscribers job to queue
4. Fires PostPublished event for other listeners
5. Clears related caches

We'll use a service class to keep controllers thin, and queues for email notifications so publishing is fast.

Is this flow what you had in mind?

设计完成后

文档：

• 将确认后的设计写入 docs/designs/YYYY-MM-DD-<feature>-design.md
• 包含：功能概述、数据库架构、API 端点、业务逻辑流程
• 将设计文档提交到 git

实现（如继续）：

• 询问：“准备好开始实现了吗？”
• 创建实现检查清单
• 考虑采用测试驱动开发方法

核心原则

• 一次只问一个问题——不要一次提出多个问题，让人应接不暇
• 优先使用选择题——在可行时，选择题比开放式问题更容易回答
• 严格遵循 YAGNI 原则——移除不必要的功能，保持简单
• 优先遵循 Laravel 约定——先使用 Laravel 内置功能，再考虑自定义方案
• 探索替代方案——确定方案前，始终提出 2-3 种方案
• 渐进式验证——分节呈现设计方案，并逐节确认
• 保持灵活——遇到不明白的地方时，回头澄清

Laravel 专属注意事项

构思 Laravel 功能时，请考虑：

架构：

• 这是单体应用，还是需要微服务？
• 哪些设计模式最合适（仓储、服务层、操作）？
• 如何扩展？

数据库：

• 需要哪些关系？
• 为提高性能，需要设置哪些索引？
• 是否应该使用多态关系？

性能：

• 是否应该使用队列？
• 采用什么缓存策略？
• 有哪些预加载需求？

测试：

• 需要哪些工厂？
• 使用功能测试还是单元测试？
• 如何测试任务/事件？

安全：

• 通过策略还是门面进行授权？
• 需要哪些验证规则？
• 是否需要速率限制？

构思会话示例

Claude: I see you want to add a comment system. Let me understand the requirements.

First question: Should comments be nested (replies to replies) or just one level deep (replies to posts only)?

User: Just one level - comments on posts.

Claude: Got it. And for moderation, which approach:
A) All comments published immediately
B) Comments from new users require approval
C) All comments require approval

User: B - new users need approval.

Claude: Perfect. For notifications when someone comments:
A) Real-time via Laravel Echo and WebSockets
B) Email only
C) In-app notifications (database)

User: In-app notifications.

Claude: Excellent. Let me present the design...

[Design sections follow]

Laravel 常见设计讨论主题

• 身份验证流程（SPA 与传统方式）
• API 设计（REST 与 GraphQL）
• 实时功能（Pusher、Socket.io 与 Reverb）
• 文件上传策略（本地与 S3）
• 多租户方案
• 支付集成（Stripe、Paddle、Cashier）
• 搜索实现（Scout、Elasticsearch）
• 管理面板（Nova、Filament、自定义方案）

请记住

目标是制定清晰、可执行的 Laravel 设计，使其：

• 遵循 Laravel 惯例
• 使用合适的 Laravel 生态系统包
• 易于测试和维护
• 解决实际问题，避免过度设计
• 可以逐步实现

持续提问，直到充分了解需求，然后分成小块进行设计，并逐一验证。