AO 赢得开发者青睐的最佳策略：低代码开发

我们在上篇《AO 生态的胜利之匙：Web3 时代的微服务架构》已经讨论了采用微服务架构（或者说 Actor 模型）的优势，以及它为应用开发带来的复杂性。同时在结尾中提到，公链之争其实就是争夺应用开发者的战争。那么在竞争如此激烈的公链赛道，AO 要如何赢得开发者？

当然是继续向已经获得 “大规模采用” 的 Web2 学习。这不仅包括学习其基础设施，还包括开发方法论、开发工具和软件工程实践等各个方面。

低代码开发平台绝对是 Web3 领域值得大力投入的一个方向。我的意思是，我们可以把应用开发的相当部分的 “复杂性” 转移给低代码平台。

我首先想要澄清一下 Low-Code（低代码）和 No-Code（无代码）的区别 —— 当然，这只是我的个人看法：

• 低代码是针对专业开发人员的。业界对低代码平台应具备的核心功能已达成共识（事实上的标准）。底线是它们必须采用 "模型驱动 "的方法。

  
  

• 无代码指的是一大类面向 "最终用户 "的工具。对于什么是 No-code 业界没有统一标准。它们允许用户创建简单的应用程序，如产品广告页、在线问卷调查、个人博客等。只要某项工作，以前大家认为需要开发人员才能完成，现在借助某个工具的帮助，可以由普通用户完成了，这个工具就会被称之为 No-code。

那么，我所谈论的低代码平台的 “事实上的标准” 是什么呢？你可以参考以下链接的阐述。

https://www.dddappp.org/#what-is-a-true-low-code-development-platform

你可能听说过“表单驱动”的低代码平台或者“表格驱动”的低代码平台，但在这里，我特指的是“模型驱动”的低代码平台。你可以将我的描述理解为对“低代码平台”概念的狭义解释。

传统应用的低代码开发平台已经进入了成熟的早期阶段。有人可能会说：“我似乎没有听说过‘模型驱动’的 Web3 低代码开发平台。” 确实，这是一件相对罕见的事物。让我们来分析一下原因。

首先，为什么传统的低代码平台没有进入 Web3 领域？我认为，主要是因为它们所采用的建模范式并不适用于 Web3。

传统的企业平台使用 E-R 模型和/或关系模型。例如，OutSystems 同时使用 E-R 模型和关系模型；而有些平台则只采用其中一种。E-R 模型和关系模型在概念上是相似的。这些平台生成的代码可以在传统的企业软件基础设施（如 SQL 数据库）上运行。但它们很难在 Web3 基础设施如区块链上运行，因为区块链上的“去中心化账本”与 SQL 数据库差异太大。

那么，现有的去中心化应用“低代码平台”表现如何呢？

开发一个真正的低代码平台 —— 尤其是采用模型驱动方法 —— 并非易事。有些人可能会试图回避这项艰巨的工作。但是，专业低代码平台的核心功能具有其他解决方案无法比拟的独特价值。例如，“可配置的智能合约模板”可以帮助开发人员更快地复制“现成的代码”，但对于那些创新应用来说，这些模板并无太大用处。对于平台开发人员来说，用不同的语言（如 Solidity、Move 等）编写和维护一个适用于多个链的“智能合约模板”库也是一个巨大的挑战。此外，“智能合约”只是应用程序的链上部分，稍微大一些的去中心化应用程序通常还需要链下部分。

dddappp：真 Web3 低代码开发平台

那么，是否存在一个不投机取巧、勇于直面挑战的 “真正的” —— 采用 “模型驱动” 方法的 —— Web3 低代码开发平台？

我非常自豪地宣布，我所在的团队开发的 dddappp 是一个真正的去中心化应用低代码开发平台。它很可能是目前唯 —— 个采用“模型驱动”方法的 Web3 低代码开发平台。

那么，dddappp 到底有何独特之处？它为什么可以做到其他平台（最少是暂时）没有做到的事情？

关键是 dddappp 采用的建模范式。我们选择了 DDD 风格的领域模型。

DDD 风格的领域模型是一个相对高层次抽象的 OO（面向对象）模型。自动化工具可以很容易地将这样的高层次的领域模型映射到低层次的实现模型，如面向对象编程模型、关系数据模型等。

什么是 “高层次抽象” ？这么说吧，它尽可能多地帮助你表述你对领域的认知 “是什么”，而不是技术细节上解决问题要 “怎么做”。

有经验的开发者马上能理解这是一件说起来容易做起来难的事情。我们能做到这一点，完全是因为机缘巧合，我们在这个领域积累了丰富的经验 —— 我们从 2016 年就开始做这个事情了。我们甚至写了一本书来向开发者们分享我们的经验。

关键在于，我们发明了一种用于领域建模的极具表现力的 DSL，名为 DDDML（“领域驱动设计建模语言”英文的首字母缩写）。使用它，不仅可以准确地描述领域知识，还可以轻松地将这些模型映射到软件实现代码中。

对了，与其他 "竞争对手" 相比，我们的 DSL 更贴近问题领域和自然语言，我们相信这使得它能够与人工智能（AI）完美结合。

我们自己一直把 DDDML 称为“DDD 原生 DSL”。

还记得我之前提到的来自 DDD 的“聚合”概念吗？我们使用的 DSL 从一开始就支持定义聚合，打开任何一个 DDDML 模型文件，你几乎都能看到 aggregates 这个关键字。

如果你熟悉 DDD 的相关概念，会很容易看明白 DDDML 所描述的模型；如果你不熟悉，那也不要紧，DDD 既有经典著作的系统性的论述，更有拥趸们与时俱进的实践经验， 只要你愿意“拿来”，它们几乎是唾手可得。

DDD 方法论的强大底蕴常常给我们带来惊喜。我们在开发传统应用（其后端主要由 Java 或 C# 编写）时，就一直在使用“领域模型驱动”的方法，极大提升了开发效率。当我们进入 Web3 的新天地后，我们发现，不用给 DDDML 增加太多的东西，就能够使用它来驱动去中心化应用的开发。

dddappp 如何帮助 AO 生态应用开发?

在这篇文章的前半部分，我们谈到了使用 AO 开发应用面临的一些挑战。

那么，dddappp 采用的技术方案能真正帮助到 AO 生态的开发者吗？请看我们最近完成的一个基于 AO 的概念验证。

在这个演示里面，我们相信有些问题我们已经提供了非常有吸引力的解决方案。我们演示了如何使用 DSL 定义聚合、值对象、服务（这些都是 DDD 的概念），展示了生成代码的大致样貌。你可以想象一下，如果不用工具，开发人员真的愿意手写这些代码？特别是，我们还演示了生成的代码如何使用 SAGA 模式优雅地实现 “最终一致性” 的处理。

我们把这个演示称为 PoC，但是实际上我认为它已经超越了 PoC。因为它现在就可以马上帮助到 AO 生态的开发者。AO 生态的开发者现在就可以使用它来理清应用的设计思路、生成代码（这些代码最少可以作为实现参考）、提升效率。从某种程度上来说，这个工具你已经可以说它是一个 MVP（最小可行产品）。因为 MVP 的定义是，只要能够帮助到最终用户，对最终用户有价值，那就可以称之为 MVP。毕竟，开发者就是低代码工具的最终用户。

如果有经验的应用开发者仔细研究过这个 PoC，他们就完全有理由不再怀疑低代码方法在提升应用开发效率方面的巨大潜力。毕竟，我们在 AO 生态之外已经多次证明了这一点。即使不提我们在 Web2 时代使用相同方法开发过的复杂商业应用，单单观察我们在 Move 生态中的实践，也足以让人信服。

我们利用 DSL 解决了 Move（一种静态智能合约语言）缺乏 “接口” 抽象的限制，帮助开发者轻松实现 “依赖注入”， 详情请见该链接示例：GitHub - dddappp/sui-interface-demo

我们可以通过简单的声明将 Move 合约拆分成多个包（即 “项目” ），见该链接示例：GitHub - wubuku/aptos-constantinople。需要注意的是，大多数 Move 公链对每次发布的包的大小都有限制。

如果你认为我们分享的只是一些 “示例”，我们可能只是在制作一些玩具，那你就大错特错了。

我们深度参与了一些严肃的商业应用的开发（主要集中在 Move 生态）过程，在这个过程中，我们几乎就是一直在 “吃自己的狗粮”。我们可以非常自信地说，目前，至少在后端（我指的是链上合约和链下查询服务，后者有时候被称为 indexer）开发领域，我们兑现了 10 倍开发效率的承诺。

我们甚至基于“低代码”开发“无代码”应用（再啰嗦一遍：无代码工具是面向最终用户的应用）。我们在 Aptos 新加坡黑客松上构建了一个副产品，叫做 Move Forms，获得了当期第二名的好成绩。我们会利用“业余时间”持续地构建这个 Web3 原生表单工具。

如果你联系我们，我们可以向你展示更多生产级的案例。我们的案例包括了社交，DeFi，全链游戏等。

不少人可能对低代码平台可以开发的去中心化应用的类型有疑问。说实话的，我们目前没有发现低代码方式对可开发的应用类型有什么明显的限制。我们在应用开发过程中，感受更深的是当前 Web3 基础设施的局限性，而非低代码的局限性。

我不知道大家有没有发现一个有趣的现实，就是传统低代码平台，大家会普遍认为它们比较开发企业软件（比如 OA、CRM、ERP 这些），而不适合开发互联网应用；但从我们展示的内容看，似乎 dddappp 已经突破了这种限制？你的感觉没错。当初我们之所以在 Web2 时代要做这个事情——基于 DDD 领域模型驱动的低代码平台，这在 Web2 时代是一个非常大胆的尝试， 就是想“让低代码平台可以开发大型互联网应用”。

"AppCU" 也许是打开 AO 生态的突破口

虽然 Lua 和 WASM 的组合很好，但是老实说，短时间内，我无法想象依靠它们能将那些用传统上以 Java、C#、PHP、Python 等语言编写的大型 Web2 互联网应用程序（如亚马逊、淘宝、eBay、Shopee 等）迁移到 AO 上。

正如之前所述，AO 是一个数据协议。理论上，任何人都可以使用自己喜欢的编程语言开发自己的“实现”，并接入 AO 网络，与其他单元进行交互和协作。

在 AO 网络中，应用的业务逻辑在计算单元（Compute Units）中执行。因此，对于应用开发者而言，他们最希望看到的是计算单元在支持的开发栈方面更加多元化和包容。据我所知，AO 开发者社区已经在这个方向上努力，例如支持在 AO 上运行 EVM 智能合约等。

然而，我认为这个问题也许可以从另一个方向取得突破。我相信 AppCU 是一个好主意。AppCU，我指的是 Application-specific Compute Unit。用 Appchain（Application-specific blockchain）做个类比，有助于理解我的意思。

如果把计算单元排除在外，AO 的其他部分，从某种程度上来讲，可以看作一个 Web3 版本的 Kafka —— 一个去中心化的消息代理。让传统应用的开发者可以使用他们熟练的语言和工具，基于一个类 Kafka 的消息代理，来开发微服务架构的应用 —— “哈哈，这一套我熟”。

从零开始构建一个 AppCU 对大多数开发者来说可能并不容易，构建一个 Appchain 也同样如此。因此，在这种情况下，一个得心应手的工具是必不可少的。

我想，不必再强调 Cosmos SDK（用于构建 Appchain 的工具）在 Cosmos 生态发展中所发挥的重要作用了吧？

那些尝试过 Cosmos SDK 的开发者，一定会对这个工具的便利性和强大功能印象深刻。如果 Cosmos SDK 能够做到，那么 AO 生态的开发者社区也没有理由做不到。不管怎么说，开发一个计算单元比开发一条链总是要简单一些吧？

Cosmos SDK 确实是一个“高效率”工具，但严格来说，它并不是一个低代码平台。我们相信低代码平台在提升开发效率方面有着更大的潜力。

AI 是否会取代低代码平台？

最后，我想要谈谈一个我回答了无数次的问题：“AI 会干掉低代码平台吗？”

在我看来，AI 近些年取得的巨大进展并没有为复杂软件开发的方法论带来什么本质变化。即使 AI 参与到复杂应用的开发过程中，它仍然有必要遵循 “正确的” 方法 —— 就像人一样。

软件工程中每一个层次的抽象都有它的价值。开发复杂软件第一个正确的“姿势”，就是要先做好业务分析、领域建模。而使用自然语言无法精确地描述“对领域的认知”，这极大地阻碍了“将其转化为软件代码”的效率。

dddappp 的最独特之处在于它使用的 DSL。正是有了它，dddappp 可以使 AI 可以专注于它最擅长的事情：

1. AI 推荐参考模型，并辅助我们迭代模型。

   
   

• 我们可以通过自然语言和 AI 交流，让 AI 帮助我们分析需求、推荐参考模型。AI 拥有海量的知识，这是它们擅长的。

  
  

• AI 将领域模型以 DSL 输出，这样的领域模型（最少语法的正确性）可以使用工具来验证。

  
  

• 如果没有误用 DSL，低代码工具的实现也没有 bug，那么，从模型生成的代码，准确率可以说是 100%。这不是生成式 AI 通过“文字接龙游戏”产生的代码可比的。

  
  

• 低代码工具直接从模型生成可以执行的应用。这个阶段，建模可以先忽略 “对象的方法”（也就是操作业务逻辑的细节）。生成的应用马上就可以跑起来。

  
  

• 用户和开发者先确认 “数据模型”。如果有问题，反馈给 AI，让 AI 帮助调整模型，低代码工具重新生成应用。

  
  

2. AI 辅助实现 “操作业务逻辑”。

   
   

• 确定模型后，应用开发者在一个个非常特定的上下文里面对业务逻辑进行编码。在这样的一个清晰的上下文，IDE 很容易生成高质量的 prompts 提交给 AI，然后 AI 可以回复准确率很高的代码片段。

  
  

所以，我对这个问题的回答是：不。我们认为两者会相得益彰 —— 最少对于 dddappp 如此。

综上，我们解析了低代码开发平台的定义以及它对于降低 Web3 应用开发复杂性的巨大潜力。基于低代码平台的理念，我们可以在 AO 生态中构建出一个类似 Cosmos SDK （Cosmos 生态中用于构建 Appchain 的工具）的强大工具，并利用这个工具去构建 AppCU，这样既可以降低开发者开发的复杂性，也给 AO 生态取得大规模采用打开一个新的思路和可能性。

该文章仅作为观点陈述，不作为任何投资建议。