第1章：平台选型与架构解析
做低代码这几年，我经常被问到同一个问题：「这么多平台，到底选哪个？」
说实话，这个问题没有标准答案。但有个原则我一直坚持——先看架构，再谈选型。你想想看，如果连平台的底层逻辑都不清楚，选型就像闭着眼睛买鞋，合不合脚全靠运气。
1.1 主流低代码平台对比
先聊聊我接触最多的三个平台：OutSystems、Mendix、明道云。它们代表了三种不同的设计哲学。
| 维度 | OutSystems | Mendix | 明道云 |
|---|---|---|---|
| 定位 | 企业级高代码低代码 | 模型驱动+协作 | 表单驱动+轻量级 |
| 核心语言 | 自家语言+扩展C# | Java/微流 | 纯配置 |
| 适用场景 | 核心业务系统 | 复杂工作流 | 内部管理工具 |
| 学习曲线 | 陡峭 | 中等 | 平缓 |
| 扩展性 | 强 | 中 | 弱 |
我在项目中遇到过一家制造企业，他们用OutSystems重构了ERP系统。为什么选它？因为业务逻辑太复杂了，表单驱动根本兜不住。反过来，有个创业团队用明道云搭了个客户管理系统，三天上线，成本不到两千块。
核心观点：没有最好的平台，只有最匹配的场景。选型前先问自己三个问题——业务复杂度多高？团队技术能力如何？未来三年会不会重构？
1.2 平台核心架构：模型驱动 vs 表单驱动
这两个概念，我建议你彻底搞懂。说白了，它们决定了你的开发方式。
模型驱动
模型驱动，就是先定义数据模型，再生成界面和逻辑。Mendix和OutSystems都是这条路。
举个例子，你要做一个订单系统。模型驱动的做法是：
1. 定义Order实体（字段：id, customerId, totalAmount, status）
2. 定义Customer实体（字段：id, name, phone）
3. 建立关联：Order belongsTo Customer
4. 系统自动生成CRUD页面和API
5. 通过微流（Microflow）编写业务逻辑我个人习惯用模型驱动做复杂项目。因为数据模型一旦稳定，后续的界面和逻辑调整就非常安全。我记得有一次，客户要求把订单状态从「已发货」改成「配送中」，模型驱动下只需要改一个枚举值，所有关联页面自动更新。
表单驱动
表单驱动正好反过来——先画界面，再绑定数据。明道云、简道云都是这个路子。
同样的订单系统，表单驱动的做法是：
1. 拖一个「订单表单」组件
2. 添加字段：客户名称、金额、状态
3. 设置数据源（通常是Excel或简单数据库）
4. 配置审批流程
5. 发布使用嗯，这里要注意。表单驱动上手快，但有个坑——数据模型是隐式的。你拖出来的每个字段，背后没有严格的实体关系。一旦业务复杂起来，数据冗余和一致性问题就会爆发。
避坑指南：我曾经帮一个客户收拾烂摊子，他们用表单驱动做了个进销存系统。半年后数据对不上账，因为「入库单」和「出库单」的库存字段是各自独立的，没有统一的数据模型兜底。最后花了三周重构，代价惨重。
1.3 如何根据业务场景选型
讲到这里，你应该能感受到：选型不是拍脑袋，而是匹配。
我总结了一个简单的判断框架：
- 场景一：内部管理工具（OA、CRM、项目管理）
- 推荐：表单驱动平台（明道云、简道云）
- 理由：需求变化快，团队非技术，上线要快
- 场景二：核心业务系统（ERP、MES、供应链）
- 推荐：模型驱动平台（OutSystems、Mendix）
- 理由：数据关系复杂，需要长期维护，性能要求高
- 场景三：混合型（部分核心+部分管理）
- 推荐：Mendix（模型驱动为主，支持表单快速搭建）
- 理由：兼顾灵活性和规范性
我的一个小技巧：选型前先画一张「业务复杂度-技术能力」四象限图。横轴是业务复杂度（低/高），纵轴是团队技术能力（弱/强）。落在「高复杂度+强技术」象限的，果断选模型驱动；落在「低复杂度+弱技术」象限的，表单驱动就够了。
最后说一句。低代码不是银弹，它解决的是「重复劳动」的问题，而不是「业务理解」的问题。你选对了平台，只是拿到了好工具。真正让项目成功的，是你对业务的理解和架构的掌控力。
下一章，我会带你深入模型驱动的核心——数据建模与实体关系设计。到时候咱们聊聊，怎么用实体关系图把业务「翻译」成系统。