关于低代码技术架构的思考

        我们经常会看到很多低代码系统的技术架构图，而且经常看不懂。是因为技术架构图没有画好，还是因为技术不够先进，有时候往往都不是。

        比如下图：

        

        一个开发者，看到的视角往往都是技术层面，你给用户讲React18、Mysql8.1。用户是不会理解的，这些技术名词是电脑才懂的、或者是开发者才懂的。

        如果想让人能看懂，我觉得有以下几个要点：

技术实现和产品实现相对应

        低代码的底层技术实现可以对应到：

        公有云->用户数据存储在别人服务器，私有云->用户数据存储在自己的服务器

        不是讲Linux和Docker，而是讲自动化部署和运维，等等。

技术架构图是人和人沟通的媒介

        技术架构图不只是描述了哪些技术名词，更重要的是描述了哪些抽象或者实体的名词，以及他们的关系。

        人和人沟通最大的障碍不是语言，而是沟通的时候不在同一个纬度。技术架构图就是为了提高沟通的效率和拉通对话的频道。

        你跟用户讲磷酸铁锂电池、三元锂电池、刀片电池，用户听不懂，但是你讲：我们的电池续航600公里，半小时充满，-40度-100度温度下测试1万次撞击0起火。用户就感兴趣。

        同理，你讲领域模型、企业平台系统，用户不懂。你讲我们可以1小时搭建一个CRM系统，用户会感兴趣。

技术架构图是人和AI沟通的媒介

        未来，技术架构图也会是人和AI沟通的媒介，不仅人能看懂，AI也能看懂，并且生成对应的技术名词和产品架构图。

        我认为的技术架构图不仅是产品地图，也是人和人沟通的媒介。

        架构师的作用在于消除设计中的不可逆的决策。