我和我的系统们：DataHub是什么------重新思考软件的构建方式（上篇）
就像《技术的本质》一书中提到的 "工程师只喜欢那些他们能解决的问题"，DataHub 算是我一直未能很好解决的系统，所处理的问题可能也恰巧是我不喜欢的。但在构建 DataHub 的过程与经历对我个人成长的价值与意义又足够的重要，以至于间接影响了我的职业选择。所以他也成了我必须要去解决的问题。
重新认识问题
我对工程师的评价可以分为三类，合格的工程师解决问题，一流的工程师发现问题，而糟糕的工程师创造问题。我并不总是合格的工程师，但我清楚的知道成为一流的工程师是我的追求。回溯开始构建 DataHub 的日程，大部分时间是被催促着前进的，加之存在诸多环境因素的干扰，且自身又处于一种别扭的心理状态。似乎没有办法去冷静的审视待 DataHub 去解决的真正问题是什么。
现在让我们循着一流工程师的脚步，先尝试发现问题，也就是在构建面对企业用户的系统软件时遇到了什么障碍。
面向企业用户的系统软件产品，我个人认为主要面对两个问题，这两个问题的本质是因为企业经营规模的差异而产生。
（一个是💩难吃，一个是💰难挣，如果兼顾的话，那真是吃着💩，还没赚到💰。）
面对大中型企业，那么系统软件的差异化问题就无法避免，对于系统软件提供商来讲就无法避免定制化来满足差异性。而且作为软件提供商即便落地了多家大中型企业客制化，并且能够将这些定制化的需求，抽象提炼融合到自身产品中。在面对下一家大中型企业时依然摆脱不了定制化的命运。
为什么会如此呢？可能的原因还是企业之间的竞争本质，而这来源于其商业模式在细微处的差异。除非是面对一片未开拓的蓝海，市场供不应求。否则一样的商业模式，两家企业间没有差异的情况下，如何赚取符合企业增长与运营的资本呢？
因为经营差异的必然存在，那么就使得面向大中型企业的 SaaS 系统软件产品本身成为了伪命题。不仅无法形成规模化，因交付形式最终都会走向项目实施的结局，甚至都难以为软件提供商贡献有效的 ARR（Annual Recurring Revenue）。
面对中小微企业，如果不是有行政力量的强制，其对系统软件诉求并不迫切。那么对于软件提供商来说，所提供的系统软件产品自身并不重要。而他们看重的可能是附着在产品上的外部价值，另外，他们同样有着客制化的诉求。
就如同国内市场早期大中型企业纷纷落地 ERP 一样，看重的也是 ERP 背后的生产制造经营管理体系。换句当年时髦的话来讲就是真正需要的是赋能。
如果抛开附加价值，那么软件提供商的竞争几乎是同质的，加之营商环境的现状，小微企业存活时间并不持久，所以付费意愿不强烈。那么就导致各家系统软件提供商陷入价格的比拼。不过，好在市场总有新的挑战者进入，但是这些每年更迭的小微企业对于软件提供商来讲均是可争取的，这无疑进一步推高了 CRC（Customer Acqusition Cost），又因为 ARR 受所服务企业的存续所影响。导致仅仅服务于该领域市场的软件提供商的体量也很难持续增长。
如果不满足偏安一隅，系统软件供应商是不可能彻底放弃大中型企业市场的。而面向大中型市场的供应商又多少会觊觎中小微企业市场的用户体量。
但适用于大中型企业的软件系统无法直接套用到中小微企业，不单是复杂度不同，其交付也存在天然差异。
先说复杂度，大中型企业的系统软件复杂度体现在两个方面，模型复杂和流程复杂。两者叠加后，体现在用户界面上，则演变成了功能的交错与复杂的交互。这也导致，每家企业都有一套属于自己话语体系的数字化系统，同样是企业正式员工的一道门槛。
再说交付，这里将交付分为交付方式与交付产物两部分。中小微企业多数 "开箱即用"，交付方式可以归为用户自主，交付产物可以就是系统软件的产品门户。而大中型企业可能在售前、售中阶段，需要专业的咨询人员对系统进行非常复杂的参数化配置，以满足初期的定制化内容。交付产物小到可执行文件，大到一整套运行环境，甚至可能是定制化的交付产物。
这些可能就是面对企业用户的系统软件所面临的问题。
重新定义问题
上文中提到的问题其实并不新鲜，但凡在相关领域工作的人，很快便会意识到这些问题。所以在求解的道路上不仅不孤独，且有许多成功、可借鉴的产物矗立在这条道路两旁。
针对 定制化/客制化 的一种解题思路，正是此前非常热议的话题，即 "低代码/无代码" 解决方案。且随着近几年的发展逐渐趋于成熟，那么今天恰巧是个重新看待此方案不错的时机。
这种成熟带来的是趋同性以及瓶颈期，也就意味着进入了发展的阻塞期。我们能看到的绝大多数解决方案都在尝试去做 IDE（Integrated Development Environment），而这套 IDE 的思路则将 低代码/无代码 解决方案带到了研发人员认为不好用，产品及业务人员不会用的尴尬境地。其带来的研发成本的降低与效率提升的目标则变得不那么容易考证，很可能是进一步通过不会被纳入统计的加班时长所换来的。
那么研发门槛降低了吗？一旦产品朝向 IDE 的方向发展，那么自然会演变成专业的生产工具，不说系统研发，就视频编辑与图像处理相关软件的教程充斥网络的现状，便可得出答案了。
但是这里有一个意外，而且似乎非常意外，其普及率与使用率在 "低代码/无代码" 解决方案中高得离谱。那就是问卷调查类程序的管理后台。你只要在手机或电脑上填过问卷，那么背后一定有人用过对应的平台通过拖拉拽的方式生成这份问卷。而且用户无需过多时间便可以上手构建一套电子问卷，几乎可以无师自通。
为什么会这样？
如果我们稍许观察便会发现，制作调查问卷的 "低代码/无代码" 平台，其拖拉拽的组件与逻辑是围绕着调查问卷这一业务场景展开的。也就是说用户所操作的每个元素均有其业务语义，是给懂业务的人所用的。
就好像类似 Photoshop 的软件固然专业，但广大用户对图片的编辑是基于自身的需求场景而展开的，而基于这些场景提供可适量的编辑参数，使得此类软件有了广大的需求，并真正地降低了修图的门槛提升了效率。我们可以带着对这两类软件的区别往下思考。
饭桶戴老板有一句写得好："所谓软件，本质是用成千上万行代码 '封装' 了开发者对某一种业务场景的理解和解决能力。"
不承载业务含义的 低代码/无代码 解决方案是来自于研发工程师对程序的理解，而不是对某一种业务场景的理解。不具备具体业务语句的 无代码/低代码 解决方案与编程语言无异，这可能也是为什么 Excel 支持 VBA（Visual Basic for Applications）的原因吧？
而这种思路通常是朝着解决所有问题的能力在努力，但很难展现高效地解决业务问题的能力。
所以，低代码/无代码 平台如果不能够与产业，或者说是具体的业务结合起来，即便能够提供细粒度的原子化前端组件，并可以细化到数据表级建模的能力，于生产力而言都是天方夜谭。但似乎诸多探索者都在朝着这个错误的方向疾驰前进。
(研发会觉得既然到了这个地步，为什么我不去写代码？产品业务会觉得既然如此，为什么不招一个研发？)
系统软件复杂性的本质在于其承载的领域知识的复杂。企业内部的解决方案中，低代码/无代码产品则通常隶属于技术中台等纯研发部门。而开源的 低代码/无代码 解决方案则更难触及本质，多数在做着将 JDK（Java Developer's Kit）封装一遍的事情。
这多少也说明了为何是调查问卷类产品的低代码化走在了行业前列，毕竟其业务并不复杂，易于形成标准化的解决方案。其次，每套问卷基本上只会使用一次，不会涉及频繁的变更与调整这样的迭代过程。
所以一种理想中的 低代码/无代码 的解决方案，应该按照领域驱动设计的角度为出发点，提供统一语言的业务领域组件。如果商品上架作为一个业务组件，那么该组件除了包含基本的商品属性信息外，还需具备上架这一业务操作背后的控制流与审判流。
那么对于使用者来讲，低代码操作的部分是对商品属性的修改调整，对上架这一业务流程的编辑，如关键信息完整便可上架，或必须有库存才允许上架，以及商品上架所经过的审判流程的定义。具备业务含义的组件一方面降低了使用门槛，另一方面对其可调整配置的部分则展现了定制化与客制化的能力，同时业务组件的粒度刚好合适其迭代与积累，进而形成行业内的标准组件。
至此，我们所面对的问题似乎变成了如何构建面向企业客户的领域驱动 低代码/无代码 解决方案？
DataHub 是什么
低代码/无代码 的业务领域表达是通过业务领域组件，领域组件背后所对应的则是领域服务，而组成领域服务的正是行业背后的标准化接口与真实代码构建的原子化服务。除非是颠覆性的商业模式创新，否则同行业间的差异经过拆分后其实都体现在微观层面。那么落实到系统软件层面则可能表现为同一接口的不同实现。这些不同实现的组合就是对领域服务的差异化表达。
如此一来，一个业务领域组件背后可能是一组接口，一个完整的业务场景可能由多个领域组件协同完成。那么一个商业背后的数字化系统则是为满足不同业务场景而聚合起来的领域组件及其背后的接口，根据企业特点加载不同实现下的领域服务。
在这样的平台下开发系统软件，就好比是编写一份声明式文档。而平台基于声明式文档生产出专属的系统软件。而 DataHub 就是这个平台的核心枢纽。那么到了这里，我想我终于可以试着说明 DataHub 究竟是什么了。
首先 DataHub 并不是一个恰当的名字，这个名字与其承载的能力，在为他人解释 DataHub 是什么时带来了许多困扰。不过叫什么名字不重要，我们先讲清楚这个系统承载的能力。
DataHub 的最基本能力包含对接口与服务注册，接口及服务间的模型与协议转换。同时提供基于接口及服务的编组能力，可针对编组粒度进行多维度的管控。在此基础上，能够针对编组内接口及对应服务进行流程编排，最终通过声明式API 组合成业务领域组件所使用的领域服务。
在系统架构层面我们将其分为数据面与控制面两个部分，在数据面完成通信协议及领域模型转换，并实现服务按声明的方式组织调用，执行完整的领域服务逻辑流程。通过与基础设施的映射提供领域服务开发测试期间的沙箱环境。
而控制面则可以认为是 DataHub 所承载的整个企业系统软件面向研发的用户界面，在其上不仅提供了系统完整的领域能力全景图，还可基于接口及服务通过 DSL（Domain-specific Language） 进行领域服务的开发。通过对数据面的观测能力，促使服务间依赖组成的业务链路实时展现。那么理想情况下，通过 DataHub 的加持，整个企业数字化系统的全貌得以清晰展现，或许将成为可能。
还记得上面提到的企业客户系统软件交付产物的区别吧？采用 DataHub 进行混合集成比较容易联想到，还有另一种方式提供的服务同样符合协议转换，那便是同一进程内软件包或模块的方式。使得控制面与基础设施间形成合力，构成 DataHub 自身的软件构建能力生产对应软件包/模块以及镜像文件。满足差异化的交付产物。
DataHub 正处于基础设施及服务与 低代码/无代码 编辑器（如：上篇中的 Studio 等 低代码/无代码 产品）中间。通过整合基础设施能力，管控组合原子化服务，以运行时声明式 API 的方式，定制化构建软件的工具平台。
最后，请让我以一个更贴切的名字来称呼 DataHub，一个朴素且不显得形式主义的名字，就叫 "领域能力工厂" 吧。
尾声
对于架构师而言，系统就是他的名片。很遗憾，DataHub 没能成为我的名片。原因是多方面的，但究其根本只能是时也，命也。
可当我写下这些文字之后，这种遗憾的感觉便消失了，换来的是一片内心的平静。以回忆、梳理的方式重新解构这个系统，我也逐渐地将原本模糊的部分，连成了清晰的轮廓，让诸多疑问有了清晰的眉目，而这便已足够，很多事情则显得没那么重要了。