详细设计说明书SaaS.docx
《详细设计说明书SaaS.docx》由会员分享，可在线阅读，更多相关《详细设计说明书SaaS.docx（122页珍藏版）》请在冰豆网上搜索。
详细设计说明书SaaS
详细设计说明书
《SaaS统一信息化平台》
文档一旦发布，请务必按文档执行并坚持遵守。
如果您有改进的建议，请将您的建议发邮件或当面告知所列作者。
修订历史记录
版本
日期
作者
修正原因
1.0
2013-05-23
蔡源
初始化文档
1.1
2013-08-30
蔡源
增加【定制化、个性化】章节
1.2
2013-09-29
蔡源
增加自动登录的设计
1.3
2013-10-15
蔡源
增加参数字典设计
增加客户管理设计
1.4
2013-10-18
蔡源
增加应用场景及解决方案章节，用于描述特定业务流程或者功能流程的实现
1.5
2013-12-04
蔡源
增加【团队协作】相关设计，主要包括项目管理和任务管理
1.6
2013-01-15
蔡源
增加用户与租户空间一对多的设计，用户可以在不同空间中切换
1.7
2014-05-05
蔡源
参数字典增加filter和params属性，用来根据业务过滤和获得额外参数
1.8
2014-05-16
蔡源
细化具体的子系统和具体的功能模块
1.9
2014-05-22
蔡源
细化QuickView，增加动态查询条件定义和动态表格定义
1.10
2014-06-19
蔡源
增加DynamicSearch，支持动态组合查询条件
1.11
2014-06-26
蔡源
增加系统公告模块
1.12
2014-06-27
蔡源
更新参数字典编号规则为：
模块名+属性名，全局唯一
1.13
2014-08-20
蔡源
增加【文档管理】模块定义
增加【项目文档】模块定义
1.14
2014-11-10
蔡源
增加【个人文档】模块定义
1.15
2014-11-13
蔡源
快速视图和动态查询条件增加descr属性，作为tip浮动显示，因为只显示名称太短了，无法详尽描述这个视图的功能
1.16
2014-12-03
蔡源
细化OA协同办公的基础功能模块
1.17
2015-01-06
蔡源
增加【业务角色】设计，用于配置数据访问权限和字段访问权限
1.18
2015-02-01
蔡源
将概要性内容转移至《概要设计》，仅保留具体设计部分
1.19
2015-02-05
蔡源
增加租户配置信息设计
启用AppStore设计，每个业务子系统通过AppStore来进行管理
增加“系统版本定义与升级”
1.20
2015-02-27
蔡源
客户信息增加收货地址属性
1.21
2015-03-27
蔡源
细化MVP所需的功能模块说明
1.22
2015-05-11
蔡源
细化消息中心的事件推送和任务提醒；
删除【文档管理】，统一使用网盘；
增加通用数据权限设计
1.23
2015-06-03
蔡源
增加图片服务的说明
1.24
2015-06-24
蔡源
配置管理重构，基于obj+json-text方式存储，而不按单个属性存储
1.25
2015-06-30
蔡源
调整tag表设计
1.26
2015-07-02
蔡源
TODO增加公开和场景功能，提升协作效果
1.27
2015-10-10
蔡源
联系人增加isFav属性
1.28
2015-10-10
蔡源
基础平台功能修订，调整表结构
1.29
2015-10-19
蔡源
增加“系统自动升级”
1.30
2015-10-20
蔡源
增加对业务日志的实现方案设计
OpLog增加opComment属性
1.31
2015-10-21
蔡源
增加Portal组件的详细设计
1.32
2015-10-25
蔡源
拆分“平台运营系统”为“平台管理系统”和“平台运营系统”，将运营类分开
1.33
2015-11-12
蔡源
增加【业务关注与消息通知】的设计
1.34
2015-12-04
蔡源
附件表新增recordUid
1.35
2015-12-18
蔡源
增加公告的缩略图、统计等
1.36
2015-12-29
蔡源
增加运营中心基础表设计
1.37
2016-01-18
蔡源
增加通用的数据权限表
1.38
2016-03-10
蔡源
增加【通用自动编号组件】的设计
1.39
2016-03-18
蔡源
增加【数据关联表】设计
1.40
2016-04-11
蔡源
增加【用户抄送】设计
1.41
2016-04-27
蔡源
增加实名认证相关字段
1.42
2016-05-23
蔡源
增加workStatus字段
1.43
2016-05-25
蔡源
增加用户余额的设计，支持充值提现
1.44
2016-06-15
蔡源
TenantMember增加微信关注相关字段
1.引言
编写目的
详细设计的主要任务是对概要设计方案做完善和细化。
说明书编制的目的是说明一个软件系统各个层次中的每个程序（每个模块或子程序）和数据库系统的设计考虑，为程序员编码提供依据。
本文档在概要设计的基础上，进一步完整详尽的描述了系统实现的技术细节，及根据业务需求制定的系统所需要实现的业务功能，功能模块的详细定义。
背景
参考资料
术语定义
缩写
英
中
2.SaaS设计
多租户模式
数据隔离
将每个承租者的数据隔离到不同的数据库。
共享数据库，Multi-Schema，将每个承租者的数据隔离到独立的表和模式。
共享数据库，Share-Schema，在所有承租者之间共享一组相同的表和模式。
实现多租户的三种模式
无共享，完全独立：
每个租户独立使用一套应用程序和一个数据库，应用与数据库均不包含租户信息，通过访问入口路由到指定租户的路径上。
优点：
无需修改原有应用程序跟数据库。
租户间不会相互影响，可对个别租户做自定义。
缺点：
部署跟运维相对繁琐。
物理设施资源开销最大。
无法对多租户数据进行查询归并，存在数据孤岛
共享应用，多数据源：
使用同一套应用程序，数据库访问时根据租户信息路由到指定数据库或Schema上。
优点：
兼顾了开发和性能。
缺点：
无法对多租户数据进行查询归并，存在数据孤岛
共享应用，单一数据源：
使用同一套应用程序，使用同一个数据库，数据模型中定义了租户信息，通过过滤条件过滤租户数据。
优点：
性能最优，部署简便
缺点：
对系统架构和开发工程师要求较高，否则可能存在数据安全性问题
运维复杂，当数据发生异常需要恢复时，无法简单依赖数据库的恢复机制，并将影响到多个租户的数据
数据过滤
在共享同一数据源的模式下，需要对每个数据查询增加租户信息的过滤条件；在单app环境下，一个用户只对应一个租户，通过登录用户信息即可获得租户信息，比较简单。
但是在平台模式下，一个用户可以租用多个app，用户与租户是一对多的情况。
解决方案：
用户在登录一个app时，app通过appKey去平台获取该用户的信息，并在本地session中保存用户登录信息，平台可以根据appKey与用户ID获得唯一的tenant，即app本地session中只需保存用户对象与tenant对象一对一的关系。
只有用户在登录平台系统时才有一对多tenant的情况。
总结
实际使用中可能综合运用3种模式，即如果客户较为重要，愿意为安全性、性能等额外付费，可部署为独立模式。
常规情况下则使用共享数据库模式，但根据性能或部署需要，可能根据用户数切分为多个domain，每个domain中的用户共享一个数据库，这样如果某个domain失效，不会影响其他用户的使用。
但基本原则是所有数据表均按SaaS模式设计，以便实现不同模式下的切换。
定制化、个性化
定制化指的是同一SaaS服务可以为不同用户在相同基础功能的基础上提供一定程度的功能定制或强化，在不改动或尽量小改动服务的基础上实现不同用户的差异化功能性需求。
如：
数据模型的定制化，业务流程的定制化。
个性化指的是为客户提供的，满足用户企业或个人个性需要的非功能性需求，如国际化、主题、收藏夹、菜单结构调整、Logo或程序名调整、Dashboard等。
门户、流程、智库、社区
注：
所有方面，不仅是为了解决企业内部问题，更可以推向上下游，如企业门户网站就是对外的，通过BPM可集成上下游的业务系统，实现供应链的业务流转并最终实现E2E。
智库可以形成企业最佳实践和解决方案，可以在行业中共享和推广。
社区更可以通过人与人之间的关系，加强企业间沟通。
注2:
4个类别，都是强调信息的汇聚、共享、传播，通过SaaS模式可以实现这些方面的最大化，这是传统单一企业内部信息化无法实现的。
通过门户来集成分散的功能，信息，提高用户对关键信息的关注度，提高用户对信息的获取和处理效率。
通过流程来组装分散的业务，实现上下游业务的E2E一体化，提高业务协作能力，提高业务间信息共享，并最终提高企业整体业务的处理效率。
（注：
流程可能在某些环节的处理效率会比以前降低，但其目的是优化整体效率）
通过智库来积累知识，沉淀企业智慧。
知识的有效积累可推动企业业务流程重组和优化，加强企业文化建设，提高员工凝聚力。
社区是强调企业人与人之间的沟通，有别于上面三项都是以企业运营为目的的。
---这个待定
MetadataDB
元数据数据库，定义了多租户相关信息，用于租户信息管理，作为基础的公共服务独立于业务系统数据库。
系统用户角色
租户拥有者
租用app的用户，作为app的拥有者，其拥有app的所有功能模块使用权限；同时作为拥有者，可以对app进行续费、升级、停用等操作。
此外作为app的第一个默认用户，也是默认的租户管理员（租户开通时默认创建），具有租户“系统管理”模块的功能权限，可以在租用范围内创建角色，邀请其他用户加入，分配权限。
租户管理员
租户拥有者出于管理角度考虑（如租户拥有者是老板，但是管理员是IT管理员），可以将租户中的任意用户提升为系统管理员，由其作为租户管理员协助或负责租户内相应的管理工作，如用户管理，角色管理，功能权限分配，邀请用户加入等。
租户管理员在权限上与租户拥有者一致，但租户拥有者作为最高级别，可随时将租户管理员降级成普通用户；而反之则不行。
租户成员
租户开通后，默认只有拥有者一个成员，此时拥有者可通过邀请方式请求其他用户加入到该租户中共同使用租用的app。
如：
老板租用了CRM系统，邀请公司内部员工加入到该系统中，员工即可使用CRM系统的功能，并在租户范围内共享数据。
用户在加入一个租户后，需要租户管理员为其开通相应功能模块的使用权限（通过设置角色），否则只能共享【个人事务】中公开部分的数据。
客户用户角色
系统管理员（内部）
管理系统用户、角色与权限，保证系统正常运行。
高管（内部）
审查客户贡献数据、客户构成数据、客户服务构成数据和客户流失数据。
客户经理（内部）
维护负责的客户信息。
接受客户服务请求，在系统中创建客户服务。
处理分派给自己的客户服务。
对处理的服务进行反馈。
创建销售机会。
对特定销售机会制定客户开发计划。
执行客户开发计划。
对负责的流失客户采取“暂缓流失”或“确定流失”的措施
销售主管（内部）
对客户服务进行分配。
创建销售机会。
对销售机会进行指派。
对特定销售机会制定客户开发计划。
分析客户贡献、客户构成、客户服务构成和客户流失数据，定期提交客户管理报告。
销售人员（内部）
接受销售任务，负责与客户接触，实施销售任务，跟踪客户消费。
合作伙伴（外部）
部分数据交互，并提供合作伙伴关心的数据，可由合作伙伴自行访问（SelfService）。
供应商（外部）
部分数据交互，并提供供应商关心的数据，可由供应商自行访问（SelfService）。
客户（外部）
提供客户关心的数据，可由客户自行访问查询（SelfService）
身份验证与授权
身份验证和授权是现实应用程序的安全性概念中主要的两个：
身份验证允许一个应用程序在连接时验证一个人（或一个应用程序、智能卡等）是否与它声明的一样。
授权定义一个用户在一个系统上的权利与权限。
用户身份验证通过之后，授权会决定该用户在系统上有权做什么。
因此，授权应该发生在身份验证之后。
身份验证和授权在SaaS应用程序中很复杂。
在一个安全性SaaS解决方案中，底层的身份验证和授权基础设施有两种设计方法：
集中式或联邦式。
授权模式
黑盒模式：
即简化的权限模型，不开放授权功能给用户，角色和权限由系统内置，用户在加入App时自动绑定角色，对于一个App来说通常有：
创建人，管理员和普通成员3个角色。
白盒模式：
即允许用户授权，App创建人可在自行创建用户组和角色，并对每个功能模块进行细分授权。
该模式可实现更精细的权限控制，类似传统的企业应用。
可扩展性
基础设施可扩展性
计算资源快速供给
应用快速部署
资源按需分配
自动化管理
应用架构可扩展性
应用服务器水平扩展
数据库水平扩展
MySQLSharding（）
异步消息队列
缓存机制
负载均衡
流程可定制
功能可配置
数据权限
对于前台数据查询，通过定义数据级权限实现动态表格内容输出，不同角色的用户将看到不同列的表格及经过过滤的数据内容。
按角色定义哪些数据项可以呈现，并能调整列呈现的顺序；
按角色定义过滤条件，实现基础数据的过滤；
参数字典
参数字典分“参数类型表”和“参数字典表”。
参数类型表定义不同类型的业务参数，如用户类型、公告类型等。
每个类型又可分为：
1–不可修改，2–可增加，3–可修改，4–可删除4种。
如公告类型，可被定义为“可增加”类型的，即公告类型可以增加，但不能被修改或删除。
参数类型表另外用状态字段定义：
1–正常，2–屏蔽，9–系统。
对于某些业务需要，不需要用到的参数，可设置成屏蔽，即在业务系统中将无法使用该参数；对于状态为系统的，则不能进行此项操作。
参数字典表为明细表，对参数类型定义业务参数，如公告类型可分为：
1–公告，2–新闻，3–通知，4–紧急通知等，由于公告类型为可增加类型，故可在此基础上进行增加，但一旦使用过的公告，则不能进行修改或删除了。
对某个业务参数细项，又有3种状态：
1–正常，2–屏蔽，9–系统。
由于业务需要可暂时屏蔽某些业务参数；但对于状态为系统的则不能进行此项操作
日志记录
日志按照类型分：
操作日志、业务日志、系统日志。
不同类型的日志有其相应的处理逻辑及具体实现，以下分别说明。
操作日志：
记录操作员登录后执行的相关操作。
（目前只对更新数据库的操作记日志，查询不记录）
业务日志：
记录业务处理信息，如转账时金额的变动数额等。
系统日志：
记录系统日常运行时的行为日志，目前采用通用的日志框架，以手工编码的形式记录
操作日志同具体的业务应该是相互分离的，不在同一个事务中，及无论业务操作是否成功，都将记录用户操作。
而业务日志记录业务的详细信息，应作为业务的一部分，与业务存在同一个事务中。
因此操作日志一般在控制层编写，而业务日志一般在业务层编写。
注：
可通过注解+拦截器模式提供非入侵的操作日志记录；而业务日志一般只能编码实现。
操作日志模型
属性
名称
类型
备注
busiType
业务类型
int
0-未指定
1-保存
2-更新
3-删除
4-查看
5-查询
6-审核
...
moduleCode
模块编号
String
对所有功能模块，都有唯一对应的编号，如“系统配置”对应“SYS-001”
opId
操作员ID
Long
opName
操作员名称
String
冗余数据，这样就不需要关联操作员表了
opIp
执行操作的IP
String
opDatetime
操作时间
Date
数据库默认
content
操作内容
String
具体操作内容描述
status
操作状态
int
0-失败
1-成功
业务日志
业务日志需要记录详细的业务数据变化，无法使用Annotation在方法级进行拦截，需要硬编码实现。
考虑到一定的通用性，我们采用基于事件（Event）的日志模式，即在日志模块中通过订阅操作事件（OpEvent）获得业务模块发布的业务事件，再通过模板消息将业务参数格式化成操作详情。
需要记录业务操作日志的，在业务执行完后通过EventBus发布继承于BaseOpEvent的事件对象，操作日志模块统一订阅该事件并统一转换存储。
发布事件代码示例：
说明：
业务操作的名称将通过国际化转换成对应用户语言，国际化KEY命名规则：
[模块编号].func.[功能编号]；
日志详情基于动态参数格式化，因此需要将必要的属性作为事件的动态参数传入，国际化KEY命名规则：
[模块编号].func.[功能编号].log。
由于某些日志详情需要生成HTML的超链，依赖contextPath，因此约定contextPath将作为默认0位传参传入，业务参数在参数数组中的位置从1开始，如下面事件中commentId的位置为{1}。
个性化
界面个性化
用户可在一定程度上对界面做定制化，如使用个性化主题，个性化布局，可自行调整菜单结构等。
系统菜单可配置性
菜单对不同的租户来说，可能有不完全一样的名字。
例如客户管理，在医院使用时，就得改成病人管理，客户服务人员就得改成医生，客户服务记录就是就诊记录等。
另外菜单的层次结构和分布，不同的租户可能也会有不同的要求。
在设计上需要考虑以下几个问题：
一个租户一套菜单；
一个菜单可以关联一个子功能；
组织成树型结构，构成上下级菜单结构；
同级菜单之间还存在显示顺序的问题
页面元素可配置性
各功能界面上的内容也是供用户和系统交互的界面元素。
不同的租户可能有各种不同的需求。
由于租户可以自定义扩展数据，这些数据是需要在页面上展示的，因此无论对页面元素的个数、位置、顺序，还是元素的含义，租户都会有一些个性化的需求。
同时对于在设计时设定的界面元素，一般情况下是不允许删除的，但有时候还是允许租户将一些无关紧要的字段隐藏。
数据个性化
在实际应用中，不同租户之间需求的差异导致系统需要针对不同租户保存许多扩展性数据。
在传统应用中，可以通过定制实例，增加客户的扩展数据，来满足其个性化要求。
在多租户SaaS应用中，所有租户都使用同一个数据架构，常见的解决办法就是实现扩展数据的可配置。
名称值对的方式将扩展数据的保存和原数据表分离，另外用一个统一的扩展数据表来保存。
扩展数据表将数据表的横向扩展列转换为纵向的数据集，将每一条原始数据记录的一个扩展字段，都保存成一条扩展数据行。
将数据表中的数据记录与配置元数据表中的配置记录关联，构成扩展数据记录。
可以提供无限数量的自定义扩展字段。
但是其增加数据操作的复杂性，查询时也要多次访问数据库才能得到完整的业务数据。
这些都会影响数据访问性能。
此外可结合使用NoSQL，通过SchemaFree模式提供高扩展性和个性化。
参数字典
不同的用户在对参数字典的使用上也会存在差异，如客户等级，有的喜欢用1、2、3表示，有的喜欢用A、B、C表示，这就需要参数字典也需要能够支持多租户，并可定制。
功能个性化
对于SaaS应用，面对为数众多的租户，大部分租户可能只会使用到应用中的部分功能。
因此系统需要支持租户有选择的使用自己需要的功能，满足功能可配置要求。
原子功能划分
要实现功能可配置，首先需要将整个系统的功能进行分解。
整个应用需要分解成最基本、相对独立、互不重叠的原子功能。
所有原子功能叠加起来，就是整个应用所提供的全部功能。
进行原子功能划分，首先就是功能分解，即将整个系统的功能分解成最基本的相对独立的原子功能，应遵循以下几个原则：
每个功能都是有价值的；
每个功能都是不可再细分；
功能间互不重叠；
功能之间不循环依赖；
整个系统功能是完整的。
将功能分解完毕后，由于不是所有的原子功能都是可以单独使用的。
有些功能是需要依赖其他功能才能使用，功能之间是存在一定的依赖关系。
因此功能分解完毕后，还需要对功能进行定义，描述相关依赖关系。
功能包设计
当系统功能被划分为许多原子功能后，直接配置原子功能给每个租户是比较复杂的。
需要根据用户类型和使用的场景，对原子功能进行打包，然后为每个用户配置其合适的功能包。
功能包的设计要遵循高内聚、低耦合的原则，尽量将相关的和相互依赖的原子功能设计在一个功能包中。
同时应该减少功能包和功能包之间的依赖，使得各个功能包尽可能独立的进行操作使用。
通过功能包的设计，虽然可以将系统功能组合成几个相对比较独立的部分，但是这些功能包仍然不可以完全独立使用，也就不能够单独销售。
为了让用户购买了系统以后可以充分使用其同能，需要按照不同的商业意图构造合适用户的销售包。
例如，按照客户使用功能的多少，可以把系统划分为最小版、标准版、完整版。
功能使用校验
在经过对系统进行原子功能划分和功能包的设计后，系统的不同租户可以按照不同版本使用了，系统需对原子功能进行校验，确定租户在系统中可以使用和操作哪些原子功能。
3.数据模型
用户信息（UserInfo）
用户信息表中只保存比较固定的数据，便于快速查询和缓存，其他经常要变的数据放到附属表中
属性名
含义
数据类型
备注
id
序号，主键
Integer
由数据库自动生成
loginId
登录ID
String
登录名
password
密码
String
密码
userType
用户类型（1001）
int
1：
内部用户
2：
外部用户（客户、供应商、合作伙伴等）
userName
用户名称
String
用户姓名
nickName
昵称
String
gender
性别（0002）
int
0:
未知
1：
男
2：
女
email
电子邮件
String
mobile
手机号
String
mobileValid
手机号是否已验证
BOOLEAN
realNameValid
是否实名认证
BOOLEAN
即userName
job
职位
VARCHAR（50）
status
状态（1002）
INT
0：
未激活
1：
正常
2：
注销（可恢复）
3：
删除（仅超级管理员恢复）
4：
锁定
workStatus
工作状态
INT
由用户手工切换
0：
离线
1：
在线
2：
休息
balance
帐户余额
BIGDECIMAL（10,2）
totalBalance
累计充值金额
BIGDECIMAL（10,2）
locale
语言
VARCHAR（50）
支持用户自定义
timezone
时区
int
支持用户自定义
theme
主题
VARCHAR（50）
支持用户自定义
headImgUrl
头像
VARCHAR（200）
头像图片路径
createDatetime
创建时间
DATETIME
updateDatetime
更新时间
DATETIME
升级会员 