jxTMS：低成本快速定制的业务开发平台。

jxTMS-业务数据模型

在前几天关于一个无代码的回答【无代码编程会是以后的趋势吗？】中，笔者大致讲了下不同的研发思路。

就本质来说，拖拽自搭建的方案其实是以数据为核心的呈现技术，是基于一个完备的业务处理系统，让业务人员根据自己的业务需求就地找数据、取数据、看数据、用数据。即系统处理好数据，让业务人员自助使用。

理解了这一点，想到jxTMS的实现中是以业务逻辑为中心，所以数据的操作与呈现是一体的，确实需要为自助使用做下准备，所以在借鉴了华为数字底座的治理方法论后，依托既有设施实现了jxTMS的业务数据解决方案。

业务数据

经过思考，笔者形成了业务数据的概念：

业务数据是经过加工的数据，具有一系列业务属性与业务计算的业务信息集合，用来指示业务的运行，可以被其它业务环节直接利用与二次处理

比如，运输方式。在拟定合同时，选择了哪种运输方式，就包括了相应的包装方式、运费、保险费、在途时间、交付地与交付方式等一系列的业务处理结果，这些业务处理都是规范化的，具有预测算能力。所以，用户通过给出货物清单就能自动计算运费、预估时间、外包装尺寸等，即可实现业务自动化、服务自助化。

也就是说，业务数据是规范化的、自带业务计算标准接口的源数据。这里的源数据是指离开数据的生成地之后，只能被引用，但不能被修改，即谁管理谁维护，他人只能按权限引用，而不得修改。

因此，业务数据具有如下的要求：

• 谁管理谁维护，引用方不得修改，不得转发
• 基于角色的授权
• 通过元数据进行描述
• 数据指标化，即通过这些数据可测量、审计、评价具体的业务过程。目前可暂时放一放
• 数据预校验，即关联准入检测，在数据进入时进行校验，从而提高数据质量
• 内置业务规则，可随时对业务进行合规性检测，从源头保障业务的合规性
• 可计算，可随时根据实际情况进行业务测算，提高业务的战术决策水平

有了业务数据的概念，则可整合之前已经开发好的各种既有设施，从之前的侧重业务实现逻辑，变为封装业务细节为标准化业务部件，以数据流为抓手来梳理、整合业务过程，简化业务开发。

业务数据的外部访问

外部对业务数据的使用，一共有五种：

• 流：流式样的数据其实就是数据序列，类似一个根据约定用引用者所给参数执行的查询，只不过在查询出相关原始数据后，在逐行向引用者馈送前先由业务模块加以处理，再将处理后的数据提交给引用者

注：如果原始数据不符合业务要求，业务模块可能会将其过滤掉并不馈送给引用者。如量化交易需计算各交易策略的绩效，绩效的计算是以每天早八点的仓位为基准进行计算的，但一般来说，每天都会有多次交易，所以从交易流水中提取绩效数据时就会出现业务模块过滤掉交易数据的情况

• 单体：单体数据同样是一个根据约定用引用者所给参数执行的查询，同样在查询出相关数据后，先由业务模块加以处理，将处理后的数据提交给引用者。所以单体数据和流数据的区别就是一个和n个的区别
• 计算：根据约定用引用者所给参数调用标准接口来执行相关的函数并返回结果

注：计算应和业务处理的请求区分开，业务数据的计算结果只是基于现有数据的测算，不会对现有数据有任何修改与影响

• 合规性检测：对引用者按约定提交的参数调用标准接口以实现用相应的规则表对这些参数进行业务合规性的校验，如长宽高是否符合运输条件、所要求的交付量超过库存需要生产但客户要求的交付期却太短等等
• 订购：根据约定，引用者可以订阅自己感兴趣的数据或事件，当这些数据或事件产生后，负责业务数据的模块将通知订购者

流数据与单体数据，如果是类似华为的基础数据与主数据这些基本不会变动或变动很少的数据，则可以启用缓存特性。

注：基础数据、主数据、事务数据等这样的分类，jxTMS的业务数据模型作为基本模型不做区分

谁管理谁维护

这一原则的落地很简单，上一小节也指出了业务数据只有上述的五中读取类型的接口。

作为开发约定，业务数据所对应的真实数据只能在业务数据所在的功能模块中处理，包括录入、修改、整理等维护动作的实现。

授权

业务数据对象在获取时需要根据引用者的角色执行授权检查。如果授权不通过则返回空的业务数据对象，而成功获取即可以通过上述的四种方式使用而不再进行权限检查。

由于jxTMS允许一个成员有多种角色，所以只要这些角色中有一个通过授权即可。

授权是一个基于文本的、开发者可自定义的、由条件判断组合起来的公式。如代码的授权公式：

role.profession match '技术.研发.软件' and role.level >= 20
           

意即：岗位前缀为技术部门的研发类软件岗，且职级应大于等于20。这样，一个高级程序员就可以查看代码，但其领导，如果岗位前缀是【技术.研发.管理】，那是无法查看的；而岗位前缀是【技术.研发】的领导就可以查看。

注1：示例中的岗位前缀和职级都是由该组织自行设定

注2：越短的岗位前缀代表的是负责的领域越广，自然权限就应越大

预校验

预校验可参考数据约束。只不过是约束的位置从该文所指出的前后端移到了业务数据录入时的前端【设在此处也意味着在多系统的自动勾连、自动采集时也可以起到作用，而不仅仅是人工录入时的web前端】。

业务规则检查

业务规则检查可参考合规性保证，具体的实现技术可以参考业务规则。

业务计算

业务数据提供了相关的标准接口与映射框架，可以将引用者对某业务数据的约定访问自动映射为对相应capa中的某个函数的调用。

订购

业务数据只提供了关于订购的标准接口框架来衔接订购的消费者与生产者，具体的生产与消费，业务数据模型并不干涉。为了进一步简化业务数据模型的实现，目前宕机后业务数据模型本身并不会重新恢复这些订购，而是由生产者与消费者自行考虑宕机后订购的维持。

注：订购的维持可放在initAtLoad修饰的函数中执行，以确保宕机后的恢复

总结

业务数据模型通过封装业务细节为标准化的业务部件，以数据需求来组装业务，进一步简化了业务开发。由于业务数据模型的实现，jxTMS也具备了自助组装的基本能力。

笔者在10多年前就已经实现过web控件的拖拽搭建，但这种方式对非专业开发人员比较友好，可对于专业开发人员来说效率太低，由于jxTMS面向的就是专业开发人员，所以拖拽组装就暂不考虑了。