3.MRD产品目标与设计
虽然低代码从 20 年左右爆发到现在，一直不缺的就是争议，中间不断地有人力挺也有人频繁的质疑，但不可否认的是一旦在业务中引入低代码体系，或多或少都会提升研发链路中的效率，而随着开发对于业务的深入从而可以使得产品与业务的耦合度增高，那么在这个领域提高的效能也会随之增加。
质疑的声音无非是针对于低代码的使用人群、学习成本以及 Pro code 相关的问题，虽然这些绕不开但是跟上一章提到的一样，软件开发整体的发展趋势都是为了快速、简便的开发业务需求，所以整体低代码的体系展现方式可以不同，但是总体一定会继续前进。
无论技术方案是 No Code 还是 Less Code，目前市面大部分的低代码方案都在集中解决某个领域的问题，通用方案的实现就需要更多的方案适配与学习成本，虽然商业化的饼图确实非常大但这样无疑提高了产品设计、学习成本、推广成本，所以领域型的低代码也是技术产品与商业价值互相磨合妥协后的结果。
产品价值
- 成熟的业务领域可以快速地完成需求功能开发；
- 可视化的技术可以将低代码体系从研发的角色延伸到设计、产品、运营等角色，在项目开发初期的时候对项目就能做出一定的需求可行性分析与支持；
- 通过低代码生成的项目，从规范以及后续的基础模块升级等方面可以得到一定的保证；
- 全流程的自动化流程，减少研发成本以及提高项目质量。
商业价值
体现在商业价值中可以总结为下面 3 点：
- 效率：可以快速搭建基础项目，进行个性化定制，降低业务试错成本与竞争效率；
- 成本：从人力、机器资源等多方面缩减研发成本；
- 安全：规范化的流程可以保证线上的稳定性。
产品概述
市面上大部分的低代码产品都是运营、建站类型，但这些产品也有一些不足之处：
- 它们的 Pro Code 产物结构会比较复杂，臃肿的代码在性能体验上也会有所折扣，其次复杂的结构也不利于二次开发，导致产品无法保证可延续性；
- 一般这种低代码产物与自己的后端服务耦合比较多，一旦接入使用这些产品就会存在一定的业务约束，但一个稍具规模的公司是希望将数据拿捏在自己的手上，这大抵也是都想做低代码轮子的原因。
这里不把已有成熟体系的 PASS、SASS 服务商纳入，因为这种类型的公司已经将垂直领域的业务吃得非常透彻，已经 SASS 化的产品本身就已经将各个业务做成独立模块，可以自由组合搭配快速交付对应场景的业务，使用低代码只是将它们的复杂度降低，更便于客户理解、使用，同时部分低代码的产品都是与业务模块高度耦合，展示与使用方式都有特殊定制，例如地产工程、医院等客户。
而且 C 端业务的变化非常复杂，营销类型很吃业务与创意设计，如果从营销场景切入低代码产品无疑将面对一大波竟品的对线，无论业务成熟度、产品知名度都会被吊打，一个产品一定要接受不断地业务迭代才能完成迭代升级的良性循环。
另外 C 端用户的获客成本高昂、付费意识普遍低下，如果一款产品没有一定的造血能力，全靠为爱发电以及全靠输血那么最终大概率走向失败，除去非常著名的开源项目能够有足够的资源支持之外，大部分的开源项目都是因为作者的原因导致中断，比如大家可以了解下 core-js 作者的情况。
而中后台业务场景的需求量非常大但它们的布局加功能都比较固化，大部分可以基于物料 + 基础布局完成页面组装，即使存在多种不同系统之间的样式交互的略微差别，我们也可以通过主题配置的方式来兼容。
基于上述的情况，小册的低代码产品将主打通用性，功能做到与业务完全解耦，将业务场景控制在中后台管理系统中，限制产品的业务边缘，减少接入、使用与学习成本。
产品目标
小册的目标是打造一款通用性的中后台的低代码产品附带营销搭建类型的模块，所以最后呈现的终态是由数据驱动搭建 MFF 的中台产品与 C 端营销搭建业务产品两种组合而成。
MFF（Model For Frontend）
与常规的 Schema to View 的模式不一样，中台化产品的概念 MFF（Model For Frontend）有如下的一些特点：
- 无缝对接现有后端服务，尽可能减少后端业务逻辑改动，减少传统业务的改造成本；
- 解决业务复用能力设计、组件使用门槛问题以及减少现有组件接入成本；
- 减少对现有前端业务的侵入，提供 Pro Code 与 Less Code 模式，支持页面与组件级别的引入；
- 可以引入 AI 模型，可以针对不同的业务进行训练从而提供匹配度较高的 Schema。
整体的流程模型如上图所示，与市面常见直接页面拖拽搭建产品不同的是：中台化产品更关注于从服务端业务数据转换这个过程，而非搭建可视化的结果，并且产物与 Pro Code 更容易结合，下图是中台化产品的界面：
C 端营销产品
C 端营销产品和大部分可视化搭建类的架构设计一样，整个系统也采用分层的设计，尽可能将责任细化。
整个系统将整个应用分为如下洋葱🧅图所示的几个模块：
- 最底层是搭建协议，基于标准化的协议，可以将区块、模版快速引入到当前编辑器的内容编排当中快速完成工作，也可以将定义好的页面组件保存为自定义的区块、模版后期直接一键使用；
- 第二层是编辑器层，这一层主要实现了根据底层协议来装填物料、页面内容编排、画布预览区域的渲染器显示；
- 第三层是针对编辑器的一些扩展开发，如组件平台可以管理远程的组件，资源管理可以控制编辑器设置器中的一些素材，页面管理可以对编辑器保存和发布的页面进行管理，应用服务可以将编辑器保存的数据存储起来下次再使用；
- 最顶层就是聚合前面几层组合的搭建平台，由于是分层设计的原因，可以在多个不同的项目中来扩展使用搭建服务。
项目骨架
整体的项目骨架先总结一下，后面在实现时会在单章中分别深入解释对应的作用与实现过程:
- 组件与功能区域：用于填充本地与远程的物料组件，提供给使用者不同的能力；
- 操作栏：针对画布级别的
render的一些操作渲染，如常见的清空与回退。在所有的平台上都以看到它们的身影； - 画布：所见即所得，负责承担用户编排组件时实时预览的效果，同时还要支持组件的操作；
- 属性面板：提供给用户编排的能力，操作选项和物料组件的属性支持是一切效果的基石。
项目截图
下图是项目 C 端营销搭建产品部分的前端页面截图：
- 页面列表
当前已经保存或发布的页面列表。
- 工作台编排
页面编排工作台，专心 DIY 你的页面显示。通过拖拽组件到渲染器当中，可以进行复制、删除、移动、撤回、抹除等图层方面的组件操作
研发时间轴
整体的研发时间轴将按照上图来进行，先将进行后端业务逻辑开发，在大体模型开发完毕之后进行客户端对接，完成整体的项目开发。
小册的实际工程由 CookieBoty 与 wangly19 分别开发中台化与 C 端营销搭建两个产品。
MFF（Model For Frontend）的概念是由之前的同事玉门、沧枫等搭建团队成员一起讨论出来的中台低代码方案，由于业务原因，我们会面对非常多的中台系统，为了快速解决复杂但又单一的需求，最后选择只做数据与视图的中间层方案来快速适配各端的需求。
此章节的内容会随着项目的更新进度不断优化
写在最后
如果你有什么疑问或者更好的建议，欢迎在评论区提出或者加群沟通。 👏