软件设计方法论

使用 Zion 进行应用开发，虽然省去了编写底层代码的步骤，但依然遵循成熟软件开发的工程逻辑。本章将引导你从一个初步的想法出发，通过结构化的思考，将其转化为一个稳定、可用的生产级应用。

软件开发生命周期

一个成功的应用通常会经历以下几个阶段。Zion 将这些复杂的工程步骤简化为可视化的操作，但核心逻辑依然通用。

1. 需求分析与 MVP 规划

核心目标：想清楚“做什么”和“给谁用”。 关键动作：梳理核心功能点，规划最小可行性产品 (MVP)。避免“功能蔓延”。

2. 数据建模

核心目标：设计应用的底层数据结构。 关键动作：绘制 ER 图（实体关系图），确定数据表及表之间的关联。在 Zion 中对应数据模块的配置。

3. 原型与 UI 设计

核心目标：设计应用的视觉界面和用户动线。 关键动作：规划用户旅程，使用容器和组件搭建界面布局。在 Zion 中对应设计模块的拖拽操作。

4. 逻辑实现

核心目标：实现交互逻辑和业务规则。 关键动作：配置前端交互和后端行为流。在 Zion 中对应行为模块的配置。

5. 发布与运营

核心目标：交付用户并持续迭代。 关键动作：一键发布上线，根据用户反馈快速迭代优化版本。

第一步：MVP 思维与需求梳理

MVP (Minimum Viable Product，最小可行性产品)。新手最容易犯的错误是试图一次性复刻一个功能完备的微信或淘宝。

建议策略：

做减法：只保留最核心、最能解决用户痛点的功能。
小步快跑：先上线核心功能，收集真实反馈后再迭代新功能。

实战：梳理一个“在线课程应用”

假设你要做一个售卖课程的应用，可以这样拆解：

明确痛点：讲师需要变现知识，学生需要购买并学习内容。
核心角色：
- 学生：浏览课程、购买、观看视频。
- 讲师/管理员：发布课程、管理订单。
MVP 功能清单：
- ✅ 课程列表与详情展示
- ✅ 支付集成 (微信支付/Stripe)
- ✅ 视频播放功能
- ❌ (暂缓) 社区论坛、积分商城、直播互动

第二步：规划用户旅程

用户旅程是用户在应用中完成某个目标的操作路径。清晰的路径规划能让你在搭建页面时心中有数。

示例：学生购买课程的旅程

进入应用：从分享链接或搜索进入首页。
浏览筛选：在课程列表中看到感兴趣的标题和封面。
查看详情：点击卡片进入详情页，查看简介和试看视频。
下单支付：点击“立即购买”，唤起支付窗口。
支付成功：系统确认收款，跳转到“我的课程”页面。
开始学习：点击已购课程，开始播放完整内容。

💡

提示: 在动手搭建前，建议用纸笔或思维导图画出这个流程，标记出需要哪些页面（如首页、详情页）和哪些数据（如课程表、订单表）。你也可以咨询 AI 助手来帮助你。

第三步：数据建模

这是无代码开发中最关键、也是最体现工程思维的一步。数据模型决定了应用能存储什么信息，以及信息之间如何关联。

核心三要素

数据表：应用里的核心对象（如 账户、课程）。
字段：数据表中的每一行存储的信息（如 课程名称、价格）。每个字段都需要一个确定的类型，如文本、数字、日期、布尔值、图片、文件、JSON等。
关系：数据表之间的联系。
- 1:1 (一对一): 一个账户只有一个详细档案。
- 1:N (一对多): 一个账户可以有多条订单；一个分类下有多门课程。
- N:N (多对多): 一个学生选多门课，一门课有多个学生(学生是账户的一个子集)。多对多关系需要创建中间表

💡

提示: 在 Zion 中，每个表都默认包含 id、创建时间、更新时间 字段。

id: 记录的唯一标识。
创建时间: 记录创建时间。
更新时间: 记录更新时间。

实战：设计“课程应用”的数据表

基于上面的需求，我们需要设计以下核心数据表：

数据表	核心字段	说明
account (账户表)	id (长整数), 头像 (图片), 昵称 (文本), 邮箱 (文本), 手机号 (文本)	存储账户基本信息及鉴权信息。
course (课程表)	id (长整数), 标题 (文本), 封面图 (图片), 价格 (无限精度小数), 视频 (文件), 简介 (文本)	存储课程内容信息。
order (订单表)	id (长整数), 状态 (文本), 金额 (无限精度小数)	存储交易记录。
enrollment (用户拥有课程记录表)	id (长整数)	账户-课程多对多关系的中间表。记录哪些用户可以访问哪些课程。

关键关联关系：

account - order (1:N): 记录“谁”买了单。
course - order (1:N): 记录这个订单买了“什么”课程。
account - enrollment (1:N): 一个账户可以有多条用户拥有课程记录。
course - enrollment (1:N): 一门课程可以有多条用户拥有课程记录。
account - course (N:N 通过 enrollment): 通过 enrollment 中间表关联账户（用户）和课程。用户所有已购课程可通过用户的用户拥有课程记录访问。

详细“数据内容”请参考: 数据模型。

第四步：UI/UX 设计

UI (用户界面) 关注视觉与美观，UX (用户体验) 关注易用性与交互流程。

实战：设计布局

首页：
- UX 策略: 采用网格或列表布局，重点突出“封面图”和“价格”以吸引点击。
- Zion 实现: 使用绑定了 course 表数据的 列表组件。
详情页：
- UX 策略: 顶部放置试看视频。底部固定悬浮“立即购买”按钮，方便移动端单手操作。
- Zion 实现: 利用 默认布局的相对位置 进行排版，结合固定位置实现底部按钮。

建议阅读：布局与定位。

第五步：逻辑实现

有了界面（皮）和数据（骨），最后需要通过 行为（前端交互） 和 行为流 将它们连起来。

实战：配置“购买逻辑”

当用户点击详情页的“立即购买”按钮时，系统需要执行一连串逻辑：

三个关键环节：

1. 创建订单记录 —— 服务端安全处理 在发起支付流程之前，必须先在服务端创建订单记录。⚠️ 关键安全原则：订单创建逻辑必须放在行为流中执行，而不是前端直接操作数据库。

配置：创建一个 行为流，在其中配置以下逻辑：
1. 接收前端传入的课程 ID 和用户 ID
2. 在服务端查询课程数据，获取真实的价格和库存信息
3. 进行必要的校验（如库存充足、价格有效等）
4. 使用服务端获取的真实价格创建状态为 待支付 的 订单 记录
5. 返回订单 ID 和金额给前端
目的：
- 🔒 防止价格篡改：前端无法修改价格、库存等敏感数据
- ✅ 保证数据一致性：服务端统一进行业务逻辑校验
- 📊 可追溯性：为后续支付流程提供可靠的订单 ID 锚点

2. 调用支付行为 —— 绑定服务端校验的上下文 当调用系统行为（如”微信支付”或”支付宝”）时，必须传递经过服务端验证的上下文信息。

配置：将步骤 1 中服务端返回的 订单.id、金额、货币 绑定到支付行为的入参中。
目的：
- 🔒 安全性：使用步骤 1 中服务端返回的金额，而不是前端可被篡改的客户端数值
- 📌 可追溯性：传递 订单.id，确保支付回调知道要更新哪个订单
- ✅ 数据完整性：确保支付网关收到的金额与服务端验证的金额完全一致

3. 处理业务逻辑 —— 后端逻辑 这是定义核心业务规则的地方。Zion 提供了一个内置的行为流，在支付网关回调时自动触发。

系统自动处理：系统会自动记录一条 支付记录 流水，并解析支付结果为不同的分支。
你的配置：在内置行为流中找到 “成功” 和 “失败” 分支，添加你的业务逻辑：
- 成功：将 订单 的状态更新为 已支付，创建 enrollment 记录授予课程访问权限。
- 失败：（可选）将 订单 的状态更新为 失败，记录错误日志并通知用户。
- 已被处理：系统自动跳过，防止重复处理。无需用户配置。
为什么：
- 前端风险：运行在浏览器中的前端逻辑不可信，用户可以通过开发者工具篡改变量或伪造”成功”信号来绕过支付。
- 后端安全：行为流运行在完全隔离的可信服务器环境中。它依赖支付网关到服务器的直接、经过验证的信号（Webhook）。由于用户无法触碰或拦截这种服务器到服务器的通信，因此无法伪造支付。

详细“行为配置”请参考: 交互模型。

通过这篇方法论的学习，你已经掌握了从0到1创建产品的路线图。接下来，让我们熟悉一下具体的生产工具——编辑器。