每日热评｜一个 Nx 单体仓库装下 ERP+CRM+HRM：Ever Gauzy 的多租户工程学拆解

每日热评一个 Nx 单体仓库装下 ERPCRMHRMEver Gauzy 的多租户工程学拆解评测快照ever-co/ever-gauzycb18696项目定位开源企业经营管理平台ERP / CRM / HRM / ATS / 项目管理 / 工时数据指标Stars 4,551 | 主语言 TypeScript | 协议 AGPL-3.0取材窗口GitHub Trending Daily (2026-09-13)作者Valhalla Matrix 治理实验室企业软件领域一直有个尴尬现实ERP、CRM、HRM 这些系统通常由不同厂商割裂提供数据难以打通。Ever Gauzy 试图用一个开源平台把它们整合起来而且做成了一个庞大的 Nx 单体仓库monorepo。今天它出现在 GitHub 趋势榜上值得我们从工程架构角度认真拆一拆。一、把六套企业系统放进一个 monorepo 的代价与收益Ever Gauzy 对外宣称覆盖ERP、CRM、HRM、ATS招聘、项目/任务管理、员工工时与活动追踪。这意味着一个仓库里要同时容纳多套前端应用Angular / React / React Native如 Ever Teams 复用其无头 API一套后端 APINestJS 生态大量共享的 libs类型、DTO、UI、工具。ever-gauzy/ ├── apps/ # 前端与后端应用含 gauzy-e2e 端到端测试 ├── packages/ # 共享库类型、UI、业务逻辑 ├── AGENTS.md # 面向 AI 编码代理的仓库契约 ├── commitlint.config.js └── jest.config.ts / jest.preset.js收益前后端共享类型定义一次改动可以原子性地贯穿全栈代价构建与 CI 复杂度上升任何“小改动”都可能触发大面积重编译。这正是它必须引入 Nx 的原因——Nx 的受影响图affected graph能把改动影响面算清楚只重建真正受影响的子项目。二、多租户是它的核心难点Gauzy 定位为可自托管、可多租户的企业 SaaS 基座其商业版 Gauzy.co 也是同一内核。多租户系统里最棘手的从来不是“把租户 ID 加到表里”而是数据隔离边界租户 A 的查询绝不能越过租户 B权限模型员工、经理、管理员、租户管理员多层 RBAC可观测性出问题时必须能按租户维度定位。它把 E2E 测试组织成了一个结构化的 BDD 支持层这在其浅克隆的证据里能直接看到apps/gauzy-e2e/tests/login.smoke.spec.ts apps/gauzy-e2e/tests/support/bdd.ts apps/gauzy-e2e/tests/support/fixtures.ts apps/gauzy-e2e/tests/support/commands.ts用fixtures.ts统一准备“租户 用户 组织”这类测试夹具用bdd.ts把业务语言映射到操作是把企业级测试从“堆脆弱脚本”升级为“可维护回归资产”的务实做法。三、AGENTS.md仓库开始为 AI 编码代理写契约一个容易被忽略的细节是仓库根部有AGENTS.md。这届开源项目正在形成一种新共识仓库不仅是给人看的也是给 AI 编码代理看的。把“哪些目录是生成的、哪些改动会触发什么、提交规范是什么”写成机器可读的契约能显著降低 AI 代理“乱改一通”的概率。这对大型 monorepo 尤其重要——代码量大到人类不可能全知AI 代理更需要明确的边界说明。四、落地与合规提醒许可AGPL-3.0。这意味着如果你把它改造成对外提供网络服务的 SaaS通常需要向使用者开放你的修改源码。商业闭源改造前务必咨询法务。依赖树企业平台依赖极其庞大务必锁版本、做 SBOM 与供应链扫描。自托管 vs 云平台支持自托管数据主权可控但也意味着你需要自己承担升级、备份与安全运维。适用场景中小企业一体化的经营管理底座、需要私有化部署且希望二次开发的团队。五、总结Ever Gauzy 真正值得学习的不是“功能多”而是它示范了如何用Nx monorepo 共享类型 结构化 E2E 面向 AI 的仓库契约把一个天然的“多系统割裂”问题收敛进一个可维护的工程体。它也提醒我们开源企业平台的护城河往往不在功能清单而在多租户隔离、权限模型和可运维性这些“看不见但决定生死”的地方。