1.1 低代码开发平台介绍
低代码开发平台是一种平台软件，人们能通过它提供的图形化配置功能，快速配置出满足各种特定业务需求的功能软件。它可简化软件开发过程、提高生产率、缩短软件交付周期，并且系统稳定性较好，只要经过简单测试即可交付使用，最终降低软件开发成本。
普通开发平台一般是通过程序员编写程序来实现软件的，对技术要求比较高，不适合业务人员实现，且软件开发效率比较低、周期比较长、成本高。但普通开发平台通过不断演化，也能实现部分图形化配置功能，逐渐向低代码开发平台靠拢，而且利用普通开发平台开发出来的软件能力几乎不受开发平台能力的限制，只受底层的某种开发程序语言能力的限制。
与普通开发平台相比，低代码开发平台强调的是，让业务人员或者技术人员通过图形化配置可视化地实现软件。它们的区别如图1-1所示。显然，低代码开发平台用户的技术门槛较低，既可以是技术人员，也可以是业务人员，或者两者协作。
图1-1 低代码开发平台与普通开发平台的区别
一个低代码开发平台的能力，不能简单地根据由业务人员还是技术人员配置来评价。一般来说，只由业务人员配置实现的低代码开发平台，配置友好性高，但是软件能力相对受限，配置出来的软件差异化程度小、灵活度低。而需要技术人员参与配置的低代码开发平台，配置出来的软件差异化比较大、灵活度更高，但是配置复杂度高，不适用于业务人员单独完成配置。
一个低代码开发平台的配置角色定位取决于平台的设计目标，设计师应该将业务人员和技术人员配置的内容清晰地剥离出来，让业务人员配置一些简单的参数，如某个权限控制限额；让技术人员配置规则，如控制某个权限的业务逻辑，将业务人员配置的权限控制限额用于实际的权限控制逻辑中。设计师可以进一步将低代码开发平台分为两个版本，分别为基础版和高级版。基础版适用于业务人员配置，将技术人员配置部分禁用；高级版由技术人员配置使用。
大部分低代码开发平台是由技术人员和业务人员双方共同参与配置的。我设计的保险核心业务系统，配置化程度很高，允许灵活配置多条保险产品线和多种流程，其中由业务人员配置的内容有产品、条款、责任、费率表和主数据等，由技术人员配置的内容有属性定义、元数据模型、规则、数据库结构、流程、界面和功能等。大部分业务配置特别简单，由业务人员单独完成，少量工作需要技术人员参与。
低代码开发平台配置出来的软件能力一般要受到低代码开发平台自身能力的限制，只能做低代码开发平台事先设计好的能力范围内的事情，不能超过该范围。因此，低代码开发平台一般具有一定的约束性，软件能力有限。不同的低代码开发平台侧重点不同，通常侧重于某个特定领域的应用范围，例如，办公自动化软件、企业管理软件等。
市场上有很多低代码开发平台，有面向行业的，也有通用的，图1-2所示的是一个低代码开发平台例子。客户关系管理（CRM）低代码开发平台可以配置实现各个行业不同用户的客户关系管理，如零售业CRM、制造业CRM和保险业CRM等。保险业务系统低代码开发平台可以配置出支持不同产品线的业务系统，如车险、非车、健康险、信用险、农险、寿险和团险等。低代码开发平台也可以非常通用，如BPM，可以经过配置和编写少量脚本实现一个具有表单录入、提交、多级审核功能的办公自动化系统，基本可以配置适用于多行业的各种办公流程的业务处理。
低代码开发平台本身也是一个软件，也是通过程序开发实现的，只是它的功能比较灵活，通过配置即可实现平常看似需要开发人员才能实现的其他软件功能。低代码开发平台自身实现比较抽象，不同低代码开发平台的实现技术各不相同，但是它们具有共同的特性——灵活性和可配置性。下面通过一个简单例子来提炼一个低代码开发平台需要考虑的问题。
图1-2 低代码开发平台举例
假设我们开发一个客户管理系统，用于维护客户相关的信息。当捕获用户需求之后进入开发阶段之前，还需要做如图1-3所示的各项设计工作。
图1-3 一般软件设计工作项
（1）设计数据结构，用来描述一位客户的信息，主要包括姓名、性别、出生日期、证件类型、证件号、手机号和地址等，以及该客户相关的账户信息；
（2）设计服务，即客户管理相关服务和规则，包括：对客户增删改查的基本服务。对于客户操作可能涉及很多业务逻辑处理，即规则，例如校验身份证号长度是否等于18位，是否与出生日期一致等，这些业务逻辑都是服务实现的一部分；
（3）设计数据库，数据库包含多张表，每张表有多个字段，分别对应于不同模型或者子模型；
（4）设计流程。修改客户信息可能需要经过一套流程，一个用户录入客户信息，下一个用户对上一个用户录入的客户信息做审核，涉及相关审批流程，每一个流程节点对应不同的功能界面；
（5）设计界面，方便用户能够通过图形化界面操作系统。
上述各项工作都是根据客户管理的实际业务需求分步设计实现的一个定制化的软件开发过程。当需求发生变化时，例如，为客户数据结构增加一个属性或者字段，对应的服务、数据库结构、界面、流程都要做相应的修改，还要经过测试，开发周期比较长。如果需求频繁变化，那么开发工作量将倍增。
不同行业需要维护的客户信息是不同的，如保险行业可能需要收集客户的健康状况、家庭住址等，银行业可能需要收集客户资产信息等。这些不同会进一步引起服务、数据库结构、界面、规则和流程的差异。如果多个用户的需求差异较大，那么几乎要为每一个用户重新开发一套系统。
除了个人客户，还有企业客户管理，企业客户的信息和个人客户的信息差异很大，通常是两个不同的数据结构。在一般企业软件中，会有两个模块或者系统分别实现对个人客户和企业客户的管理。个人客户是对自然人的管理，企业客户是对企业法人的管理。它们的操作界面、数据库结构、服务和流程都是独立开发、互不相关的。
在现实业务中，除客户管理外，还有对许许多多自然人的相关管理，例如，保险公司需要管理的自然人有代理人、公司员工、理赔查勘人员、理赔定损人员和律师等。企业法人的管理有保险公司的组织机构、银行、再保险公司和医院等。所有这些自然人或者企业法人统称为当事人，后面介绍的当事人管理系统就是指对自然人或者企业法人的统一管理，是一个低代码开发平台，具有很强的通用性，无论是个人客户还是企业客户，都可以通过简单的配置来实现不同类型的当事人之间的需求差异和同一类当事人在不同用户之间的需求差异。经过上述分析，低代码开发平台可配置性要求平台设计需要考虑如下方面：
1）模型配置允许不同行业或者不同用户，对一个领域对象进行管理时，要求体现出领域模型的差异化，如个人客户模型和企业客户模型的差异，保险业和银行业对个人客户模型的差异等；
2）数据库配置允许差异化模型经过配置后保存到不同结构的数据库表中，例如，同样是个人客户管理，由于不同行业的个人客户模型的差异导致数据库表结构不同。
3）界面配置允许对差异化模型有不同界面展现，同样是客户管理，不同行业在录入客户信息时，应该有不同的录入界面；
4）流程配置允许差异化模型可以有不同流程，例如，对个人客户管理和代理人管理应该有不同流程；
5）功能配置允许差异化模型可以有不同功能，例如个人客户有录入功能，代理人除了录入功能，还有审核功能。
总之，在设计低代码开发平台时，需要考虑平台的可配置性。而这些可配置性需求，将会导致软件设计比较抽象，不像一般应用软件设计那么直观。
不同低代码开发平台的实现机制并不相同。为了实现上述自然人和企业法人的统一管理，可以分别做两套管理功能：一套支持自然人管理，一套支持企业法人管理。两者的设计思路类似，以自然人管理为例，通常采用枚举方式，将自然人相关模型和属性、规则、数据库表结构和字段，流程、界面组件、功能事先枚举完整。面向不同用户的差异化需求，通过配置选择启用哪些模型和属性、哪些规则、哪些数据库表结构和字段、哪些流程、哪些界面组件和哪些功能，不同配置信息的差异，体现出当事人管理功能上的差异。
这种方式实现的软件属于低代码开发平台，只要对自然人管理枚举细致到位，没有遗漏，就能很好地支持多用户的个性化需求。即使同一个用户的需求随着时间推移发生变化，也可以通过修改配置，选择事先已枚举的模型、规则、字段、流程、界面和功能，快速响应需求变化，无须修改程序代码。并且，为了简化配置，可以事先内置许多常用的配置模板，对于新用户，选择一个业务比较接近的模板，并在此基础上进行少量调整，即可快速实现符合需求的软件。这种实现的设计方式与一般软件比较类似，技术门槛比较低，效果也不错，一般只需业务人员就可以完成配置。但是，可配置性的灵活度比较有限，当用户需求超过了事先枚举的范围，就需要修改程序代码。
元数据模型是另一种实现低代码开发平台的技术，它并不通过事先枚举字段和数据结构实现，而是通过元数据模型来配置数据结构，允许低代码开发平台根据具体用户的需求来配置相应的领域模型，使得数据结构可以动态变化。
关于元数据模型，后面将有详细介绍，这里读者可以将元数据模型理解为动态配置的领域模型，而非固化的模型。枚举方式和元数据模型实现低代码开发平台的方式对比如表1-1所示，这两种方式的根本差别在于枚举方式是从预置中选择模型、规则、字段、流程、界面、功能来响应软件需求的灵活变化，元数据模型则允许动态扩展模型、规则、字段、流程、界面和功能来响应，后者可以无限扩展，前者只能从事先确定好的范围中选择，不能超出该范围。
表1-1 枚举方式和元数据模型实现低代码开发平台的方式对比
元数据模型允许模型灵活变化，规则、数据库结构、操作界面、流程和功能事先也都不确定。因此，基于元数据模型的低代码开发平台是一种端到端的软件实现方案，从配置模型开始，到配置规则、数据库结构、流程、界面和功能，都具有极大的灵活性，不需要程序开发即可实现软件功能。
采用元数据模型驱动的端到端的设计思路，实现当事人管理系统，包括模型配置（规则）、数据库结构配置、界面配置、流程配置和功能配置，如图1-4所示。当事人管理低代码开发平台具有极大的灵活性，根据具体业务需求分别配置各种当事人模型（含规则），如个人客户、代理人、企业客户、医院等，然后在其上配置数据库、流程、界面和功能。
图1-4 当事人管理低代码开发平台的元数据模型端到端的实现
当事人管理的业务逻辑和流程非常简单，利用元数据模型驱动设计思想，设计出一个当事人管理的低代码开发平台比较容易。元数据模型不仅适用于简单的应用，也可以用来设计非常复杂的业务系统。比如，不同保险产品对应保险的标的不太相同，车险的标的是车，人身险的标的是人，财产险的标的是建筑物。保单是保险公司与客户签订的合同，该合同需要记录保险标的信息和保险承保条件。保险标的不同，保单模型也不相同。传统保险核心业务系统因其产品线差异性而只能按产品线分类分别实现，使得一家保险公司有多套核心业务系统，分为车险核心系统、非车核心系统、意健险核心系统、农险核心系统和信用险核心系统这就造成系统开发工作量翻倍、维护成本高，再加上多套系统并存的根源在于不同产品的保单模型、规则、数据库结构、流程、操作界面和功能的不同，因此在技术上也不能很好统一支持。我设计的核心业务系统，采用元数据模型思路，允许保单模型灵活配置，最终实现支持保险全产品线的业务管理，如图1-5所示。
图1-5 保险核心业务系统低代码开发平台的元数据模型端到端的实现
保险核心业务系统的元数据模型设计与当事人管理低代码开发平台设计思路非常类似，但保险核心业务系统中的保险产品参数配置较多，相对于当事人管理，增加产品配置功能，可让不同产品关联到不同保单模型。
元数据模型在面向具体行业时，可以做分层处理。考虑到保险核心业务系统包含多个业务模块，每一个业务模块都有灵活可配置的需求，在应用架构上引入了一层与保险行业无关的、通用的元数据平台，它也是一个低代码开发平台。在该元数据平台之上构建各个面向特定业务领域的应用模块。我设计的保险核心业务系统应用架构如图1-6所示。
在该应用架构中，中间一层是与行业无关的元数据平台，其上所有应用层以元数据平台为基础，构建各自业务组件的模型、规则、数据库结构、流程、界面和功能，这些均可灵活配置。
不同的低代码开发平台采用的应用架构各不相同，为了让平台适应各种业务场景，就涉及模型灵活可配置问题，一般采用元数据模型驱动的设计思路，即使不是完全采用元数据模型驱动的方式，也会在局部采用。一个元数模型驱动的端到端的低代码开发平台的典型应用架构如图1-7所示。
图1-6 保险核心业务系统应用架构
图1-7 元数据模型驱动的低代码开发平台的典型应用架构
在该应用架构中，包含如下几部分。
（1）元数据定义态管理。用于配置元数据结构（模型）的功能，包括：每一个数据项（属性或字段）配置、将数据项组织成一个结构的模型配置和规则配置、数据库结构映射配置等。
（2）元数据运行态管理。由于元数据的应用强依赖于元数据的结构，为了提高元数据结构的访问性能，需要将元数据结构加载到内存中建立索引，让使用者可以高效地访问元数据进行逻辑处理。
（3）元数据界面配置和展现。模型的灵活可配置性决定了系统中无法事先内置依赖于模型的界面，系统需要提供元数据界面展现配置功能，并且基于该配置信息来展现元数据实例。
（4）元数据实例访问服务。基于元数据定义，实现对元数据实例的增删改查操作。
（5）元数据实例维护功能。通过实例维护功能将实例的服务、流程和功能界面有机地组织在一起，实现对类似于当事人对象的增删改查的维护功能。
元数据模型是低代码开发平台最核心的设计思路，为了突出重点，本书将集中介绍元数据模型、数据库映射、实例服务、界面展现和实例维护等功能。模型之上的规则、流程和元数据缓存管理，本书这里不做介绍。本书余下部分将介绍如何用元数据模型驱动的设计思路来实现一个低代码开发平台。