|
数据可配置化、界面可配置化、功能可配置化、流程可配置化 SaaS可配置化：数据可配置化针对SaaS多租户模型，本文分析了如何实现拓展数据的可配置。 针对SaaS多租户模型，在实际运行过程中会发现不同的租户需要保存不同的特殊字段，例如，就拿CRM系统而言，A租户希望能保存客户纪念日，来源等，而这些数据对应B租户而言并不需要。这种系统实现过滤中并不存在，而用户又需要被保存的数据，称为拓展数据。显然，不同的客户需要保存的拓展数据可能是完全不同的。 对拓展数据的处理，在传统模式中是完全不存在问题的，因为传统软件模式一个客户对应一套软件及数据库实例，系统可是实现根据客户的要求定制化数据库实例。但在SaaS模式，多个客户对应同一套实例，如依旧采用传统定制化模式，数据库必将产生大量多余的字段，进而影响数据的性能。 针对SaaS多租户模型，对于拓展数据，最常见的解决方案就是实现拓展数据的可配置，包含如下三种主流的解决方案。 1：定制字段该解决方案更多还是在传统软件中被采用，根据用户的实际需求，在数据表中增加相应的字段。 如系统只有一个用户，那么定制字段可以完美的满足用户及技术需要。 但针对SaaS对租户模型，如还为每一个客户都添加字段，那么势必会使表中字段多如牛毛，而且随着定制字段的增多，将产生大量无意义字段，严重影响数据库性能。 2：预分配字段预分配的实现逻辑就是在设计数据表结构时，预留设计多几个无意义的字段，根据实际运行过程所需的业务要求，为对应的字段赋予实际的业务意义。 例如A客户需要额外留存订单号，那么预分配A字段的对于A客户而言保存的就是订单号，B客户需要额外需要座机号，那么预分配A字段对应B客户而言就是座机号。 预分配字段在一定程度满足租户对于拓展数据的需求，但并不是完美的解决方案，依旧存在如下不足点：
3：名称值对引入配置元数据表的概率，数据库表分为拓展数据表、业务数据表、配置元数据表。 业务数据表负责存储统一 的业务逻辑数据，拓展数据表存储根据租户需求而新增的拓展数据，而拓展数据表与业务数据表通过元数据配置表关联。引入元数据噢诶子表，实现拓展数据的横向拓展，而且完全由租户业务驱动，不造成数据的浪费及混乱。 诚然，不管是定制字段，预分配字段还是名称值对，所针对的都是数据库的设计，本文主要还是介绍产品人员怎样构建SaaS应用，对于涉及偏向技术性的问题，这里只大致介绍一下，有兴趣的小伙伴可以自行查找相关资料就行了解。 SaaS租户来源于各行各业，为适应本行业的特点，租户必然会提出定制界面的要求，而SaaS应用不可能像传统软件一样，部署时为特定的用户定制化开发符合要求的界面。因而实现界面的可配置化成为SaaS模式的必要要求。 ｜SaaS可配置化：界面可配置化SaaS应用不可能像传统软件一样，部署时为特定的用户定制化开发符合要求的界面，因而实现界面的可配置化成为SaaS模式的必要要求。要想实现SaaS界面的可配置化分别关注如下三个可配置点。 一、菜单名字可配置化不同行业有不同行业的专用术语，例如：CRM系统中的客户管理，在汽车金融公司就需要改为SP管理，客户资料管理就应该改为进件管理。这些菜单名称的配置及动态展示，是SaaS系统实现跨行业使用所必备的基本要求。 二、菜单层次结构及分布的可配置化为了更符合用户的使用习惯，菜单的层次结构及分布也需要进行可配置化，笔者在做库存监管项目时就有遇到过，有的客户需要把入库审核、出库审核、挪库审核、临时出库审核按照严格的顺序排列，而有的客户需要把各类审核统一归纳到审核管理母菜单中。 所有作为SaaS系统十分有必要实现菜单层次结构及分布的可配置，在实际操作过程中需要注意如下几个问题： 一个租户一套菜单； 一个菜单可以关联一个原子功能； 组织成树状结构，构成上下级菜单结构； 同级菜单间存在显示顺序的问题。 三、页面元素可配置 与功能菜单类似，各功能页面上的内容也是供用户与系统交互的界面元素。不同的租户可能也会有不同的定制化需求，无论是对页面元素的位置、个数、顺序，还是元素的含义，个租户都会有一定定制化需求。 前面在《SaaS可配置化：数据可配置化》中有提到，租户可根据自己的实际业务需求定制化拓展数据，这些定制化的拓展数据就会涉及到在页面展示的问题，不同的租户，页面元素个数可能完全不一样。 同时，在系统设置时，虽然一般情况下是不允许用户删除这些界面元素，但有时还是需要给予用户权限，让用户对一些无关紧要的元素进行隐藏。 同时针对同一个页面元素，不同的租户可能可能需要定义成不同含义，例如：在新建客户时，针对“客户姓名”这个标签，有的租户可能会定义成“顾客姓名”，“有的租户会定义成”代理商姓名“。另外对于元素的排序，位置不同的租户也会有不同的定制化需求。 幸好，现在网上已有大量的前端框架可实现上述的定制化要求，有兴趣的小伙伴可以自行查找 所以，对于SaaS产品实现界面可定制化，需要注意实现菜单名字，菜单层次结构及分布，页面元素的可配置。
一、划分原子功能 所谓的原子功能也就是系统最小的组成单位，原子功能与原子功能间相互独立，互不重叠，所有的原子功能具有如下原则：
划分原子功能的最基本原则就是“每个功能都具有价值“，而且这种价值是相对用户而言的。只有对用户具有价值的功能才会被用户购买。 例如新建账号时，系统会对管理员输入的手机号及信息进行验证，但这种验证只是新建账号的一个步骤，并不能为用户带来任何价值，也就不能划分成单独的一个原子功能。 除关注功能所具有的价值外，划分原子功能时，需基于既定功能架构尽量细化，做到每个划分的原子功能都是不可细分的。例如针对表单的录入，用户在创建时往往会区分新建表单和提交表单，这两个操作对用户而言都是具有意义的，所以划分原子功能时，拆分新建表单和提交表单两个原子功能，会更清晰，更灵活。 在进行分解时，还需要关注原子功能之间的关联关系，做到不可细分，互不重叠。 注意，功能的分解需要保持系统的完整性，也就是说，划分出来的所有原子功能，要覆盖整个系统的功能，而不存在没有被划分的系统功能，确保系统功能的完整性 二、功能定义及依赖 在实际操作过程中，作为产品人员，还需要对划分的原子功能进行定义和建立原子功能间的依赖关系。 所谓功能定义其实就是对原子功能进行描述，定义它的名称，关键字，内容等相关信息。其中名称和内容便于对原子功能进行详细的描述，而关键字，重在对该原子功能进行唯一标识，在系统上需要时刻确保改该标识的唯一性。 除对原子功能进行描述，在划分过程中我们会发现，并不是所有的原子功能都可单独使用，有些功能需要依赖其他功能才能使用，功能与功能间存在一定的依赖关系。 例如，很多B端管理系统都具有“查看操作日志”这种功能，但“查看操作日志”往往依赖于“查看数据列表”，如果租户没有购买“查看数据列表”这个功能，那“查看操作日志”也是不能使用的。 所谓的功能依赖，就是指一个功能在没有另外某些功能的情况下是不能使用的 。 三、功能包设计 通过划分原子，对原子功能进行定义，及设计原子功能的依赖关系。我们基本实现了对系统功能的梳理，回到我们的出发点：为应对客户的“按需购买”而实现功能的可配置。 但其实，光具有原子功能，并不能高效的实现功能的可配置。 通过逐步细化及划分，系统原子功能数量急剧增加，可达到几十个，甚至可达到上百个。直接对这些原子功能进行管理是超级复杂的事情。而且这些原子功能之间的使用并不是完全独立，很多功能操作是相关。 例如客户的新建，查看，编辑，删除这些功能都是一起使用，往往不存在单独使用的情况。并且在前一步中我们也了解到，划分的原子功能之间是存在依赖关系的，而这些具有依赖关系的原子功能总是绑定起来一起使用，从使用场景也可以看出，具有相同使用场景的原子功能不是具有操作关联性就是具有依赖性。 所以在原子功能的基础上，整合具有操作关联性及依赖性的原子功能，以功能包的形式统一管理是十分有必要的。 所谓的功能包就是一组具有关联性，依赖性的原子功能的集合体，功能包的设计遵循高内聚，低耦合的原则，具有关联性的原子功能聚合在一起，而功能包与功能包尽量减少依赖关系，进而保证每个功能包都尽可能单独的进行操作使用。 四、定义销售包 功能包已经将具有关联性的原子功能集合在一起了，但对于客户而言，定义好的功能包仍不能单独使用。所以为了让客户购买后能够充分使用系统，还需要按不同的商业意图构建适合用户使用销售包。 销售包只是一种以向用户销售而定义功能包。例如但凡成型的SaaS应用都会有最小版，标准版，完整版。或存在按客户所属行业而定义的服务行业版，制造行业版等。这些都可以称之为销售包。 五、功能使用校验 在前面已经定义了原子功能，功能包，销售包。在实际使用过程中，对用户操作权限的校验还是基于原子功能的，通过验证改用户是否具有改原子功能的操作权限，进而实现系统功能权限的控制。
|
|
|
