多租户（Multi-Tenant）应用的可配置性

1. 数据可配置性

定制字段：根据客户的需求在数据表上增加相应的定制字段来保存扩展数据。例如，根据客户33的需求，在客户表中增加来源Source和Introducer两个字段 。跟客户40的需求在客户表中增加salary和work两个字段。这种方式的缺点就是随着客户的增多，客户表的字段数据将会变的非常多，一个客户定制的字段对于另外一个客户来说是毫无意义的，严重破坏了数据表的结构。但是其不需要处理复杂的数据延伸的追踪。

预定义字段：在用户可能有扩展需求的表中预设一定数量的字段。当用户提出扩展需求时，使用其中的一个或者多个字段来保存扩展数据。其缺点是无法事先确定预定义字段的数量。

名称值对：将扩展数据的保存和原数据表分离，另外用一个统一的扩展数据表来保存。扩展数据表将数据表的横向扩展列转换为纵向的数据集，将每一条原始数据记录的一个扩展字段，都保存成一条扩展数据行。将数据表中的数据记录与配置元数据表中的配置记录关联，构成扩展数据记录。可以提供无限数量的自定义扩展字段。 但是其增加数据操作的复杂性，查询时也要多次访问数据库才能得到完整的业务数据。

2.功能可配置性

    原子功能划分

功能分解遵循的原则：

每个功能都是有价值的

每个功能都是不可再细分的

功能间不可重叠

功能间不可依赖循环

整个系统功能是完整的

并不是所有的原子功能都可以单独使用的。有些功能是需要依赖其他功能才能使用，功能之间是存在一定依赖关系的。例如，用户没有购买“产品管理”模块，那么他就不能在“客户管理”模块使用“相关产品”这一功能。

 

    功能包设计

当系统功能被划分为许多原子功能后，直接配置原子功能给每个租户是比较复杂的。需要根据用户类型和使用的场景，对原子功能进行打包，然后为每个用户配置其合适的功能包。功能包的设计要遵循高内聚、低耦合的原则，尽量将相关的和相互依赖的原子功能设计在一个功能包中。同时应该减少功能包和功能包之间的依赖，使得各个功能包尽可能独立的进行操作使用。

 

    销售包的设计

    通过功能包的设计，虽然可以将系统功能组合成几个相对比较独立的部分，但是这些功能包仍然不可以完全独立使用，也就不能够单独销售。为了让用户购买了系统以后可以充分使用其同能，需要按照不同的商业意图构造合适用户的销售包。例如，按照客户使用功能的多少，可以把系统划分为最小版、标准版、完整版。按照客户所属的行业类型，可以划分为服务行业版和制造行业版。

3.界面可配置性

系统菜单可配置性

同样的菜单对不同的租户来说，可能有不完全一样的名字。例如，CRM中的客户管理，在医院使用时，就得改成病人管理，客户服务人员就 得改成医生，客户服务记录就是就诊记录等。另外菜单的层次结构和分布，不同的租户可能也会有不同的要求。在设计上需要考虑以下几个问题：

一个用户一套菜单

一个菜单可以关联一个子功能

组织成树型结构，构成上下级菜单结构

同级菜单之间还存在显示顺序的问题

 

    界面元素可配置性

    各功能界面上的内容也是供用户和系统交互的界面元素。不同的租户可能有各种不同的需求，无论对页面元素的个数、位置、顺序，还是元素的含义，租户都会有一些个性化的需求。 对于在设计时设定的界面元素，一般情况下是不允许删除的，但有时候还是允许租户将一些无关紧要的字段隐藏。另外，同一个界面上同一个字段代表的含义可能是不一样的。例如，“客户新建”界面上有一个字段叫“客户姓名”，可有的租户就喜欢把它叫做“顾客姓名”或者“代理商姓名”。

4.流程可配置性

5.配置元数据管理

6.可配置系统运行