定义：什么是业务资产化
业务的表达需要载体，这个概念在之前我的文档里已经有过多次论述，这里就不再讨论载体和生产力的关系，但我们从载体出发，去讨论资产化以及业务资产化。
业务的载体有多种形式，代码+程序员是一种资产形式，配置+配置管理系统是另一种资产形式。而一种资产形式里，由于有人的参与，所以很难把这种组合看作是好的资产形式。而配置+配置管理系统，则是一种轻资产的形式。
业务资产化就是逐步将业务从代码+程序员的形式，转化成配置+配置管理系统的形式。
这里的配置指的是使用低代码平台所产生的物料配置，比如表单、Web、BI、工作流和审批流。
这里的配置管理系统，指的是业务运营平台，业务运营平台将各种单点的配置物料，按照业务模块的维度组织起来，在这个基础上进行：1. 业务运营，2. 业务运维。
业务运营包括：1. 产品线的迭代。2. 某一产品线内标准业务功能的迭代 3. 某一产品线内租户局部拓展的交付。
业务运维包括：支撑业务运营的、平台本身的、围绕业务模块展开的：版本管理、发布系统、基础对象维护、环境隔离等基础SRE功能。
业务划分
业务逐步资产化的第一步，是进行业务划分。业务划分后，可以业务模块作为维度，进行计划，并逐步推进资产化程度。
需要划分的业务有两大类，一类是标准功能，一类是租户局部拓展。
标准功能的业务划分，要把目前E/M/CorePaaS所有的标准业务全部涵盖在内。
而租户局部拓展的划分，1. 要考虑到目前使用CorePaaS交付过的所有租户。2. 要考虑到大量的自定义表单在租户局部拓展内如何归类存储。
划分的标准是：
- 尽量与云SaaS已有模块进行对标对齐
- 零散功能模块进行整合
- 已用CorePaaS搭建的业务自身作为一个独立模块
资产化的步骤
从总的目标来看，资产化的步骤从简单的业务模块开始，从资产化程度高的模块开始。逐步向复杂模块、未使用过corepaas的模块过度。
业务重建
从单个业务模块的角度看，资产化的步骤分为：
- 通过业务域对标，快速建立C2产品线下，与C2功能模块对标的业务域
- 针对某业务域：
- 设计业务对象模型，
- 确认基础数据/对象、确认lib1对象与lib2对象
- 根据业务对象，确认需要领域融合的接口
- 重建业务域的上层业务逻辑
- 该业务域的后续迭代，就可以基于搭建和低代码展开，实现“开发/测试”的敏捷化
这里产品经理需要画两种图，一种是业务流程图，一种是对象模型图。
业务流程图
业务流程图，举几个例子如下：
上面的业务流程图，侧重点在反应业务流程的逻辑。对照着这些逻辑，可以用工作流去描述出来。
单里面对于“对象”体现的不够突出，因此你无法直观的看出需要几个表单，几个数据对象，以及他们之间的关系。
这时候我们要再画对象模型图。
对象模型图
对象模型图就像是一个业务域的架构图，对照着对象模型图，你可以准确的把业务域内的数据对象重新定义出来，再配合业务流程图，将各个对象串联起来，进行一次完整的业务重建。
下面是一个对象模型图的简单例子：
这里我们引入了“层级”这个新概念。
先来下定义：层级是一个业务模块内部，对业务逻辑进行纵向的深度分层，用以解构业务逻辑，描述一块业务是如何由“对象”组建起来的。目前层级分为四层，分别是表现层、逻辑层、共享层和基础对象层，不同层级有不同的任务：
- 表现层。直接被用户接触到并交互的对象，比如工模具中的模具，领用申请，工模具仓库，等等。
- 逻辑层。不直接被用户接触到，用来支撑表现层、逻辑层其他对象的对象。比如某些定时器对象，某些并无实际业务意义的对象。
- 共享层。跨业务域共享的对象，放在这一层。
- 基础对象层。无任何业务意义，但是组成业务不可缺少的基础概念，比如货币，单位，时间，颜色，人，部门。
表现层
表现层直接被用户交互。用户可以去提交表单、管理数据、触发流程。
同时，表现层的对象，也可以被用户在系统里当作一种buildin的标准业务对象来选择、引用、指定，比如出现在下拉框里、在脚本中直接select等。
逻辑层
逻辑层对象默认不被用户直接交互。只是作为支撑上层（表现层）而存在的逻辑对象。
比如定时器、snapshot等类似的搭建套路，会有众多支撑对象，终端用户不感知这些对象的存在，有时这些对象并无实际业务意义，只是起一种“utils.java”的作用。
但逻辑层的对象，可以通过属性设置，变得可以被交互。
这里所谓的“可交互”分为两个维度，一个是可见性，一个是可用性。
一般来说toB的系统都是默认一个“可见即可用”的原则，因为这对大部分人的认识习惯来说是最自然的设计。在特殊情况下，会根据业务规则出现“可见但不可用”的情况，这基本都是在某些case下的限制。
在逻辑层对象来说。我们通过属性设置其可见性，这里其实是默认设置了可用性。但是对于业务case下的限制，这个需要在搭建时考虑进去，而不是指望用户自己去配置。
共享层
共享层的意义在于，这一层是“业务的边界”。
说到这里要先解释两个关系：业务域和商品的关系，业务域和跨业务域对象的关系。
我们知道，业务域、宜搭的应用，mendix的APP，其实都是基本对标的概念，都是提供了一个解决场景问题的解决方案，其中包含了该场景内的众多usecase。而根据业务的大小和复杂程度，这里的“场景”粒度是不同的。
运营平台内的每个业务域都是一个单独的业务模块，其场景粒度是可以自定义的，完全取决于用户设计和搭建的场景复杂性。
业务域之间可能有关联关系，所以带来的问题是如何确定一个业务域给用户开放权限的边界问题。比如有A、B两个业务域，如下图所示：
其中可以看到在共享层中，两个业务域都对共享对象2有依赖。当没有定义共享层这个概念，并以业务域间共享独享为界限来作为业务隔离的边界时，如何确定给用户开放哪些对象权限就会是一个非常复杂混乱的问题。而目前考察过的一些市场上比较成熟的低代码产品，基本都会把这个“跨应用”、“共享数据”、“共同引用”的对象单独抽象出来，甚至以此为基础设计出更简洁实用的上层功能。
在yida的功能中，对应的设计是“跨应用表单”，是一个收费权益；在mendix中，通过建立datahub和数据索引的方式来解决对应问题。
基础对象层
基础对象是不感知业务的底层对象。这一层的内容有如下两种：
- 对象
- 对象的数据
对象对应了表单，可以是空的表单。对象的数据对应了表单和表单中的数据，这些数据本身也是基础对象层的”元内容“，是类似于编程语言中的”buildin“的概念，是要统一开通给租户使用的。
举一个例子，在基础对象层，可能有一个对象叫”星期“，我们如何实现这个”星期“呢？首先新建一个表单叫”星期“，然后在这个表单内创建7条记录分别是”星期一“、”星期一“、”星期二“、”星期三“、”星期四“、”星期五“、”星期六“、”星期天“。我们在下发/开通的过程中，不仅要把”星期“这个数据表给租户开通，还要顺便把每周的七天数据一起开通掉，让用户可以选可以用。
这里就对基础对象层就产生了一个需求，需要能自动识别/手动设置一个基础对象，在PaaS里输出成一种搭建能力时，选择的粒度是什么：是对象本身？还是对象里的数据？
对象与领域融合线
引入两个新的概念，上文中已经提到过，这里正式的进行定义和解释。
对象
对象，是“对象模型图”的基础元素，可以理解为一个数据表。
以业务意义为维度，对象分为有业务意义的和没业务意义的。在表现层和共享层的对象，基本都会具备业务意义，比如“设备”，“订单”等等；而在逻辑层和基础对象层的对象，不一定有业务意义，可能是不承载任何业务的对象和对象数据，比如星期、性别、省份、长度单位等等。
在对象的基础上，要考虑的下一步就是，如何在搭建器中，把对象系统化的输出成一种搭建能力。
这里首先第一步仍然是做分类。分类，是逻辑学的基础之一，分类会产生范畴，范畴会有集合，集合可以提高讨论的概念维度，进一步提升命题的抽象性。分类需要维度，维度可以有是否buildin、是否业务对象 等等，这里我认为可以先暂时按照如下分类：
- 内置业务对象，buildin+业务
- 内置基础对象，buildin+基础
- 自定义对象
其中，内置业务对象和内置基础对象，用户是可以拓展字段的。用户自己创建的对象，都被放在自定义对象内。
再加上之前对字段的分类，这样整个的对象和字段，就形成了一套如下的树状结构体系：
- 对象
- 内置业务对象
- 内置字段
- 系统字段
- 自定义字段
- 内置基础对象
- 内置字段
- 自定义字段
- 自定义对象
- 自定义字段
- 内置业务对象
这样在功能逻辑上的分类就做完了，下一步就是通过功能设计和功能定义，将这种逻辑体现在产品的功能层面，输出给用户。
那第二步就应该是考虑功能的输出点和功能的输出形态。
输出点就是要找出目前的产品中所有需要使用对象的地方，以及“对象”的功能可以提升产品力的地方。
功能的输出形态，就是要考虑以何种形式让用户去用，去交互。这就涉及到了具体的技术层面的设计了。
最简单可以想到的，就是各种组件的属性配置面板，因为那里面确定的需求有对象选择器。
下面就可以想到的是模型搭建/仿真，比如mendix的模型搭建器（mendix中叫entity实体)，但这里要注意一个本质的区别：
mendix是模型构建和模型视图相分离的设计模式，可以理解为用户在模型搭建器去搭建对象，至于怎么表现，怎么在一个表单里体现出来并提供给用户去交互，那是另一回事。如下图：
而目前的CorePaaS，是将模型构建与视图构建耦合在一起，用户搭建表单（视图），就是在搭建模型对象。这也是造成某些历史债的根因所在，比如增加了字段再删除掉，其实并没有真正被删除，然后造成一系列报错/bug。
进一步发展，就是ORM层面的需求了，这时候就会接触到低代码真正的核心。比如去考虑实现APEX，实现trigger，实现在数据库层面的用户拓展，实现一种业务选择语言，像salesforce的SOQL。
因此这整个事情，就是一个比较大面积的需求，目前我们可以先实现系统化的对象输出。
领域融合线
因为目前有一套硬编码的领域SaaS，跑在一个多租户的底层基础上，而CorePaaS的发展是依托于并服务于业务的，所以我们通过“领域融合”的方式，在领域系统暴露API，CorePaaS搭建对应的表单实体，来承接融合接口过来的数据，这样就完成了API层面的兼容。
平台在将业务资产化的过程，肯定不能采取”休克式疗法“，这样风险太大，会大概率影响业务交付和业务功能的稳定性。而应该是随着业务的交付和产品功能的迭代逐步的切换。最终实现：
- 在整个公有云SaaS的粒度上，举大部分/全部业务模块，都是基于低代码构建出来的。
- 在单个业务模块粒度上，绝大部分/全部业务功能，都是基于低代码搭建出来的。
因此在之后至少1年的时间内，在思考某个业务域的对象模型和业务架构时，需要重点关注领域融合独享和领域融合线的问题，并随着功能迭代，努力将领域融合线向下推，直到所有的对象都由CorePaaS搭建产生，或者某些基础的功能性服务（比如MRP计算）直接向底层调用，将硬编码的SaaS精简到向低代码提供行业业务服务的程度。
下图是一个领域融合线的示意图，其中关注的重点有：
领域融合线，由融合对象/表单组成，每个融合对象，其实都对应了领域服务的一个接口（领域融合是以API维度进行的）
领域融合线是夸层级的，可以跨越
表现层、逻辑层、共享层存在。领域融合线一般不会到达基础对象层，除非是融合了某个底层基础服务（这时候对业务的感知性已经很低了，比如人员部门）
下图并没有太大变化，其实主要想表达的意思是，这条线是一个逻辑上存在的。在同一个层级，可能有若干对象都是融合的，甚至全部都是融合的。虽然在平面图里，我们把它描述成一条线，而如果你将这个多根树的各个节点，以及各个节点间的关联关系都考虑在内，这时候再把领域融合对象标记出来时，这个结构是立体的。
所以这个示意图，只是为了说明一个事情：领域融合线是一个辅助你进行业务架构设计时的辅助工具，而不是从一个呆板的概念。它可以辅助你搞明白“哪些对象是可以搭建的，哪些是必须融合且依赖于领域的”，并且在之后的迭代中，这个概念会辅助你继续判断这个问题。
为什么这个概念可以辅助你判断呢？我们看下图的逻辑对象3：
- 如果有一个业务需求，要迭代
领域融合线以上的业务对象，这基本可以判断，这个需求可以通过纯搭建完成，不需要产生编码需求。 - 如果有一个业务，涉及到了
领域融合线这条线经过的对象，这基本可以判断，这个需求需要进行业务重建来完成：分析改对象的内部功能架构，设计业务流程图和对象 模型图，然后将这个对象的内部业务进行重建，并把领域融合的对象向下推进，去融合更底层、对业务更不敏感、更容易搭建出来的对象，直到可以完全搭建出来为止。 - 如果一个业务，要迭代
领域融合线以下的业务对象，这时候大概率是可以通过纯搭建解决，少部分情况可能设计到新的融合。
下图和上图进行对比，展示了对于迭代涉及到领域融合对象时的前后变化。可以看出，融合的对象在逐步向基础对象层靠拢。
