学海无涯，行者无疆

对于应用开发平台的核心基石——系统管理模块，我精心撰写了一份详尽的说明手册。该手册旨在从使用者的角度出发，不仅全面阐述系统的各项属性和功能，更着重强调使用过程中的注意事项和最佳实践。在手册的编写过程中，我特别注重解释每个设计背后的原因，以及这些设计所带来的优点和可能存在的局限。这样做的目的是为了让使用者能够更深入地理解平台的设计理念，从而更快地掌握使用方法，遵循平台的设计原则，并充分发挥平台的潜力。为了更直观地展示如何基于平台进行业务应用开发，我将以一个真实的业务系统为例进行详细说明。

日志是系统的重要组成部分，往往容易被忽视。在生产环境，出现异常进行排查的时候，日志是重要的手段甚至在很多情况下是唯一可提供有价值信息的途径。从定位上说，日志可以分为几类：**运行日志：**平台启动或执行关键组件初始化、功能组件、中间件的启动和警告、报错等信息。**操作日志：**用户在系统中操作留下的记录，如访问哪个菜单，执行了哪个操作。**审计日志：**与安全相关的日志，如用户登录系统，修改密码，锁定用户等。**调度日志：**调度任务产生的日志，包括任务名称、执行时间、执行结果等。

软件系统中，会有一些成组的常量值，来描述业务实体的属性，如性别、证件类型、审批状态等。我们通常称之为数据字典，由平台来统一规划与设计，集中存储与管理，主要功能是维护字典类型以及对应的字典值，并供单据来使用。注意，这里实际是两个实体，字典类型和字典值，对应着两张库表，不过这两个实体密切相关，对于输出的数据字典功能。

在RBAC模型中，资源、角色、用户三个关键元素，构成权限体系。资源是权限控制的对象，因此常称之为权限项。平台中所有的权限项进行集中管理，菜单、按钮、请求、分组等通过类型进行区分，实体与库表公用，通过树形结构来展现其从属关系。

在RBAC模型中，资源、角色、用户三个关键元素，构成权限体系。在小型应用中，角色数量有限的情况下，单层平铺简单实用，但在大中型应用中，角色数量在几十个甚至上百个，如果依旧平铺则难以管理和使用。采用树形结构后，可以方便地添加虚拟节点（如角色分类）。角色的称呼偏技术，对于业务用户而言，称为用户组更合适，即一组用户的集合；业务意义上的岗位和职务，与传统意义的角色含义基本一致，如部门经理、固定资产接口人。

对于新系统，如果说初始化组织机构是第一步工作，那么初始化用户则是第二步工作。今天来介绍系统管理模块中的用户使用说明。对于企业应用，人员是重要的基础数据。在不少平台和系统中，对“人”的概念进一步细分，将人员与用户区分来。人员对应真实世界中的人，用户则特指具备系统操作账号的人。人员和用户的关系通常是一对一的，当然也不排除个别系统允许1个人对应多个账户。将人员独立出来，有人员没用户，意味着这部分人员，不需要登录和操作系统，如某些业务场景下的专家库。但是，这类场景下，需要根据业务需求建立单独的实体，因为要更多

平台文档是平台的重要组成部分，这块容易被忽视或不被重视。即使一个平台或系统架构优秀、设计合理、代码优雅，但文档缺失，对于平台的使用方而言，熟悉成本高、难度大。不可避免存在疑问，需要动手尝试验证或翻看源码才能确定系统的实际处理逻辑，效率低下。此外，有些平台或系统虽然有文档，但文档流于形式化，为了写文档而写文档的产物。这样的文档质量堪忧，常见的问题主要有两个：1.形式化与套路化，把功能模块和实体一列，然后增删改查，放几张截图，实际上都是些正确而无用的套话，提供的价值非常有限。2.文档与系统实现不符，没有

平台文档是平台的重要组成部分，这块容易被忽视或不被重视。即使一个平台或系统架构优秀、设计合理、代码优雅，但文档缺失，对于平台的使用方而言，熟悉成本高、难度大。不可避免存在疑问，需要动手尝试验证或翻看源码才能确定系统的实际处理逻辑，效率低下。此外，有些平台或系统虽然有文档，但文档流于形式化，为了写文档而写文档的产物。这样的文档质量堪忧，常见的问题主要有两个：1.形式化与套路化，把功能模块和实体一列，然后增删改查，放几张截图，实际上都是些正确而无用的套话，提供的价值非常有限。2.文

开源平台在ReadMe文档中简要描述了如何部署与启动以及重要注意事项，有小伙伴私信我希望提供一个详细具体的部署说明，然后联想到自己出于学习或研究目的，去搭建一些开源项目时，面对简要的说明也经常遇到障碍，比如报错了难以定位原因，反复尝试花费大量时间精力，甚至于发生折腾半天发现最终无法正常运行起来而最终放弃的情况……基于上述原因，今天来详细说说平台如何搭建开发环境，包括注意事项，这部分内容不仅适用于本平台，也适用于大部分基于主流开源技术栈构建出来的平台。如在搭建开发环境时遇到问题，请留言评论，我会及时回复。