https://xiaoshuai1024.github.io/tags/spring-boot/Spring Boot - Tag - 帅说帅话Hugo -- gohugo.ioenTue, 17 Mar 2026 09:00:00 +0800https://xiaoshuai1024.github.io/posts/enterprise-lowcode-fullstack-guide/Tue, 17 Mar 2026 09:00:00 +0800Authorhttps://xiaoshuai1024.github.io/posts/enterprise-lowcode-fullstack-guide/本文以「鲁班低代码平台」为例，给出一套可落地的企业级低代码平台全栈架构与实现路线：从组件库、设计器与运行时渲染（Render），到接入层 BFF，再到主后端 luban-backend（Java：Spring Boot + MyBatis + Redis + MySQL），最后覆盖管理后台与对外站点的交付形态。 文章目标不是“把所有代码一次写完”，而是帮你用清晰的边界把系统搭起来，并能在后续迭代中持续演进。 1. 系统全貌：六库分工，边界固定 鲁班平台由多个独立仓库组成（强烈建议保持拆分），各自职责如下： luban-ui：底层组件库（基础组件 + 低代码组件 + 设计器 + Render 运行时）。不包含管理后台应用。 luban-backend（主后端）：Java 实现（Spring Boot + MyBatis + Redis + MySQL）。提供站点、页面、用户、系统设置等原子化接口；平台 API 权威文档在本仓库维护（luban-backend/docs/API.md）。 luban-backend-go：与主后端同契约的 Go 实现，可作为参考或备用运行时。 luban-bff：Node 接入层（API Gateway）。对前端提供统一接口，对内通过 BACKEND_BASE_URL 调用 luban-backend；负责认证上下文注入（Header）与必要的协议/聚合适配。 luban：系统管理后台。负责站点接入、页面创建与管理、发布等运营能力。 luban-website：对外站点（Nuxt 3 SSR）。根据 URL 从 BFF 拉取已发布页面 schema，交给 Render 运行时渲染。 整体调用关系可以理解为： 这套拆分的核心收益是：后端契约稳定、接入层可控、前端（管理后台/对外站点）都只关心“拿到 schema 并渲染”。 2. 数据模型：站点 / 页面 / 用户 / 系统设置 后端以四类领域模型为主（详见 luban-backend/docs/API.md）： Site（站点）：id / name / slug / baseUrl / status / createdAt / updatedAt Page（页面）：id / siteId / name / path / status(draft|published) / schema(JSON) / createdAt / updatedAt User（用户）：id / username / name / role(admin|user) / status(active|disabled) / password(bcrypt) / createdAt / updatedAt SystemSettings（系统设置）：单行 JSON，承载系统级配置（站点名称、Logo、安全策略等） 关键约束：https://xiaoshuai1024.github.io/posts/ddd-domain-model-in-lowcode-backend/Mon, 17 Mar 2025 21:00:00 +0800Authorhttps://xiaoshuai1024.github.io/posts/ddd-domain-model-in-lowcode-backend/低代码平台的后端不仅要支撑「站点、页面、用户、系统设置」等资源的 CRUD，还要在 API 契约统一、多端对接（管理后台 BFF、对外站点）的前提下，保持领域边界清晰、业务规则可演进。本文从架构师视角，以 luban-backend 的实现为蓝本，说明 DDD 领域模型设计在低代码后端服务中的应用，包括战略层面的限界上下文划分与战术层面的实体、应用服务、领域异常及与 BFF 的协作方式。 一、为什么低代码后端需要领域模型 低代码后端的核心职责可以概括为： 内容模型：站点（Site）与页面（Page + PageSchema）的创建、发布、按路径访问； 身份与权限：用户（User）与认证（登录、/auth/me）、基于角色的访问控制（RequireUser / RequireAdmin）； 系统配置：系统设置（SystemSettings）的读写与缓存（如 Redis）； 对外能力：按站点 slug + 路径对外暴露已发布页面，无需鉴权（供官网等消费）。 若仅按「表结构 + Controller + Service」平铺，很容易出现： 业务规则散落在各处，修改一处忘记另一处； 错误语义不统一，前端/BFF 难以稳定处理； 扩展新资源或新上下文时边界模糊，影响可维护性。 引入 DDD 的领域模型思维（不必强求完整 DDD 框架），可以在保持实现轻量的前提下，获得清晰的边界、一致的业务语义和可演进的 API 契约。下面从战略与战术两方面结合 luban-backend 说明。 二、战略设计：限界上下文与能力边界 从业务能力出发，可将低代码后端划分为以下限界上下文（Bounded Context），与当前模块/包结构对应关系如下。 限界上下文 职责 主要实体与概念 对外暴露 站点与页面（Content） 站点与页面的生命周期、同站点下 path 唯一、schema 存储 Site（聚合根）、Page（实体，属 Site） 管理端 CRUD；公开接口按 slug+path 查已发布页 用户与认证（Identity & Auth） 用户管理、登录校验、当前用户解析 User（聚合根）、角色/状态 登录、/auth/me；Header 注入 X-User-ID / X-User-Role 系统设置（Settings） 全局配置的读写与缓存 SystemSettings（单例式聚合） GET/PUT /settings，仅 Admin 公开访问（Public） 按站点 slug + path 返回已发布页面，只读、无鉴权 复用 Site、Page，只读、过滤 status=published GET /public/sites/:slug/pages?https://xiaoshuai1024.github.io/posts/high-concurrency-lowcode-platform-architecture/Mon, 17 Mar 2025 10:00:00 +0800Authorhttps://xiaoshuai1024.github.io/posts/high-concurrency-lowcode-platform-architecture/本文基于当前鲁班低代码平台各仓库的既定关系与调用链，从高级架构师视角推演各系统的部署关系，并给出高并发优化、高可用保障、系统架构图与部署图、以及系统 Roadmap 与蓝图，便于在流量与可用性要求提升时按图演进。 一、系统关系与调用链（现状锚点） 鲁班平台由六个仓库组成，边界固定、契约清晰： 系统 职责 技术栈 下游依赖 luban-ui 组件库 + 设计器 + Render 运行时 Vue3 / Nx 无（被集成） luban 管理后台 Vue3 / Vite / Pinia / Element Plus luban-bff /api/* luban-website 对外站点（SSR） Nuxt 3 luban-bff /api/public/* luban-bff 接入层：认证、聚合、协议适配 Next.js（Node） luban-backend /backend/* luban-backend 主后端：站点/页面/用户/设置 Spring Boot / MyBatis / Redis / MySQL MySQL、Redis luban-backend-go 与主后端同契约的 Go 实现 Go / Gin MySQL、Redis 调用关系：管理后台与对外站点只访问 BFF；BFF 通过 BACKEND_BASE_URL 调用主后端（可切换 Java/Go）；主后端写 MySQL、用 Redis 做系统设置等缓存；公开页按 slug+path 读已发布页面（只读、无鉴权）。