Velrix Work Hub：重新构建一个属于自己的开源企业工作平台
为什么要做 Velrix Work Hub
企业业务系统不是从零开始理解的概念。过去参与过的 OA、客户经营、订单库存、项目交付、审批和授权管理项目，留下的更多是对业务关系和边界的认识，而不是可以直接搬运的代码。商业项目的源码、资料与设计属于原公司；早期留下的技术 Demo 又大多受限于老架构，不适合作为新的长期基础。
Velrix Work Hub 因此选择从经验重新出发：把已经被验证过的业务问题、参考资料和设计判断重新梳理，用当前的技术栈实现一套可以继续演进的企业工作台。它不是旧项目的复制品，而是一次面向今天部署、维护和扩展方式的重构。
从过去的项目经验中看到的问题
企业软件的模块边界很容易相互覆盖，却又始终不够完整。有的项目管理系统带了一部分 CRM，但 CRM 做深以后不够用；很多 ERP 带客户、供应商、采购、销售和一部分 OA 审批，但项目管理和复杂流程又偏弱；还有不少 OA 审批系统表单能力很强，一旦进入订单、库存、合同或项目状态，就只能做表单流转，无法真正控制业务。
企业最后容易先买 OA，再买 CRM、ERP 和项目管理。每套系统都有自己的用户、权限、流程和数据，客户信息重复录入，合同、订单、项目、发货和回款难以追溯，最终还要额外做接口和集成。系统买得越多，数据孤岛反而越严重。
采购模式也带来长期选择。订阅制可以降低前期投入，但用户数、功能和数据量往往持续计费；当业务延伸后，企业又可能面临私有化迁移。买断或定制化的控制感更强，但字段、流程和报表的每一次调整仍可能依赖供应商。真正需要被沉淀下来的，是能够随业务共同演进的数据关系、状态规则和审批边界。
现阶段可以做什么
当前系统已经包含 Admin 管理后台、OA 协同、CRM 客户与合同、ERP 采购销售与库存、PMP 项目管理、LMS 许可证申请与授权登记，以及统一的 Workflow 流程引擎。每个模块都有自己的业务状态与权限边界，关键数据通过稳定引用和 Application 服务协作。
Admin：先把组织、权限和运行秩序建立起来
Admin 是其他模块能够稳定运行的前提。它提供用户、角色、菜单、按钮权限、参数、字典、文件和授权审计等基础能力，并承接通知、任务调度和节假日等平台服务。业务页面可以按照当前登录用户收敛入口与数据范围，但最终的授权和状态门禁仍由服务端应用服务强制执行，避免只靠前端隐藏按钮来控制权限。
OA：覆盖员工协同与行政事务的日常入口
OA 以“人和组织”为中心。除待办收件箱、通知中心、公告和协同任务外，已覆盖员工与组织、招聘面试、入职办理、通讯录和离职办理等人事过程；请假、加班、费用、借款与还款处理员工申请；资产领用、调拨、盘点、车辆使用、维修和归还承接行政资产管理。
财务与采购协同也放在 OA 的日常入口中：付款申请可以经过 Workflow 和财务复核，进入付款批次；采购预算、采购申请和寻源记录则为 ERP 的正式采购动作提供前置业务语境。系统不会把“审批已完成”直接等同于“银行已付款”或“采购已收货”，实际业务状态仍由对应模块的规则推进。
CRM：让客户信息成为后续业务的共同起点
CRM 维护客户、联系人、跟进和销售合同。客户不是被复制到每张单据上的一段文本，而是稳定的主数据引用：从客户可以查看联系人、跟进、合同、销售订单、项目、核销和许可证上下文。存在历史引用时，系统优先停用客户而不是直接物理删除，避免留下断开的订单、项目或授权记录。
ERP：把采购、销售和库存放在可追溯的交易链中
ERP 提供商品、仓库、库位、供应商、采购订单、销售订单、出入库、调拨、盘点、核销和基础对账报表。库存余额由有效的不可变流水计算，而不是在多个页面各自维护一个“剩余数量”；收货、发货、调拨、盘点与取消都要经过状态门禁。销售订单可以带上客户、合同和项目来源，后续的发货与收款核销保留原订单关系，方便从业务和财务两个视角回溯。
PMP：把项目交付过程放回项目上下文
PMP 不是一张简单的任务表。项目可以关联 CRM 客户、合同和销售订单，维护项目阶段、里程碑、WBS 任务树、成员与主责人、计划周期和基线快照；项目组合视图汇总 WBS、风险问题、EVM 与客户应收，让项目状态不再只依赖人工周报。
围绕执行过程，系统支持项目工作项、行动项、需求、缺陷、评审、发布记录、项目日历、工时矩阵与资源负荷视图。工时按项目、成员、WBS 和日期受控登记，整周保存会先完成批量校验；需求到交付记录保留项目、需求/WBS、负责人、评审结论、发布版本与状态历史。项目变更必须经过 Workflow 审批后才能实施，避免计划与实际在无记录的情况下悄然偏离。
CRM、ERP 与 PMP 也并非各自孤立：合同审批通过后生效；销售订单可以关联客户、合同和项目；订单发货产生可追溯的库存流水；客户回款后进行核销。最终可以从客户、合同或者项目视角回看订单、发货、回款和应收余额。
OA、CRM 与 ERP：各自负责业务，不复制对方的数据
OA 负责日常协同与组织事务，例如待办、通知、请假、加班、招聘入职离职、资产、车辆、费用、付款和采购协同；CRM 管理客户、联系人、跟进和销售合同；ERP 管理商品、仓库、供应商、采购订单、销售订单、出入库、调拨、盘点和核销。它们在页面上分工明确，但在业务上通过稳定的客户、合同、订单和项目引用衔接，而不是互相直接读写业务表。
这种边界对日后扩展很重要。比如 OA 的任务与日程承载个人、部门和跨模块行动项，PMP 的 WBS 承载项目交付任务、阶段、成员、基线、工时与 EVM 约束；两者可以保留来源关系和链接，但不会被塞进一张没有边界的“通用任务表”。
为什么 Workflow 是系统的共同语言
在企业应用中，难的并不是画出一条审批线，而是在多人同时操作、异常重试、业务动作失败和并行汇聚时，仍然让状态保持可信。Velrix Work Hub 把 Workflow 设计成可被多个模块复用的运行时：它负责流程定义、实例快照、待办、通知和操作历史；业务模块仍然负责自己的状态门禁。
- 合同、采购订单、销售订单、项目变更、核销与许可证申请可复用同一套审批能力。
- 支持条件分支、受控循环、并行 Split/Join、自动业务动作，以及全员、任意、过半和固定票数会签。
- 以 Revision 与 CAS 乐观并发控制协调重复点击和并发审批；关键操作在明确事务边界中执行，并保留审计记录。
这意味着“流程通过”不是简单地改掉一条记录的状态。审批动作必须由指定审批人处理；重复发起或重复处理不能生成重复待办和通知；自动节点出错时，主业务状态不能留在半完成状态。流程运行时用幂等键、Revision/CAS 乐观并发和事务边界处理这些情况，并把关键操作保留为可回放的审计历史。
许可与设备授权：记录事实，而不是绑定密钥实现
LMS 面向需要向客户或设备交付授权的场景。它从客户、联系人、产品与特性出发，处理许可证申请、审批、授权登记、到期、重发和换机等业务记录。外部授权系统产生的 License 原文可以登记到系统中，用于保留授权事实、适用特性和有效期；密钥机制本身不被写死在产品中。
工程选择服务于长期维护
Velrix Work Hub 当前基于 .NET 10、Blazor Server、FreeSql 和 PostgreSQL 构建，优先面向 PostgreSQL 进行运行与验证，同时保留 SQL Server 适配能力。选择的出发点不是追逐技术热度，而是让事务、实体映射、部署与维护更可控。
Blazor Server 让组件逻辑和主要业务数据留在服务端，减少为了页面展示而默认向浏览器开放完整业务对象的需要。但这不是权限的替代品：权限校验、数据范围过滤、业务状态门禁和事务提交仍然统一由服务端应用服务负责。
对于大量内部业务系统而言，服务端渲染也有一个现实好处：前端不必从一开始就围绕多端 API、令牌刷新和客户端状态同步搭建复杂基础设施。文件存储、认证、打印、第三方接口和运维策略仍然需要按环境验证，但核心架构简单、依赖边界清晰，会明显降低后续服务器更换、环境升级和团队交接的成本。
数据库以 PostgreSQL 为主要运行和验证目标，利用其成熟的事务能力承载合同、订单、库存与流程实例等长期业务数据；同时保留 SQL Server 适配能力，方便已有环境按实际条件部署。FreeSql 统一实体映射、查询表达式、事务和多数据库适配，业务规则仍保留在清晰的领域与应用服务边界中。
开放源码与后续方向
项目会保持源码透明、方便扩展。企业可以按实际需求从基础管理、OA 和 Workflow 开始，再逐步接入 CRM、ERP、项目管理或继续增加财务、人事、生产、售后等模块。目标是让系统能和企业业务一起成长，而不是每发展到一个阶段就推倒重来。
面向持续演进的企业应用基础
作为模块化单体，Domain 负责业务规则，Application 负责编排用例与跨模块协作，Infrastructure 实现数据持久化与外部适配，Web 承担页面和依赖注入。这样的边界既避免过早拆分带来的分布式复杂度，也为将来的模块演进保留了空间。
让业务动作、数据关系和运行规则回到同一条链路，企业协同才能真正可追溯、可维护，也更有机会陪伴业务长期增长。
Gitee：gxrsprite/VelrixWorkHub
浙公网安备 33010602011771号