Elpis - 企业级全栈应用框架我在 my-elpis 项目中，把分散在业务代码里的通用能力抽离成了 elpis-co

Elpis - 企业级全栈应用框架

系列实战复盘（持续更新）
当前进度：已完成 Part 1「服务端内核引擎」，Part 2~5 先搭建骨架，后续逐步补全。

摘要

我在 my-elpis 项目中，把分散在业务代码里的通用能力抽离成了 elpis-core。
目标不是做一个“大而全”的框架，而是先搭建一套可演进、可维护、可复用的企业级全栈底座。

Elpis 当前规划分为 5 个部分：

服务端内核引擎（已完成）
工程化
领域模型架构
动态组件库
封装 npm 包

本文先完整复盘第 1 部分，并给出后续 4 个部分的骨架结构。

为什么要做 Elpis

随着业务增长，原始项目会出现几个典型问题：

框架层和业务层耦合，复用成本高；
新模块接入依赖手工注册，重复劳动多；
请求治理逻辑分散，排障效率低；
工程规范与架构边界不清晰，团队协作成本高。

我想解决的不是单点问题，而是交付体系问题。
所以 Elpis 的方向是：把工程能力沉淀为框架资产，让业务开发聚焦业务本身。

Elpis 的五大组成（总览）

Part 1：服务端内核引擎（已完成）
Part 2：工程化（骨架已建）
Part 3：领域模型架构（骨架已建）
Part 4：动态组件库（骨架已建）
Part 5：封装 npm 包（骨架已建）

Part 1：服务端内核引擎（已完成）

1.1 阶段目标

第一阶段只做“必须有”的能力：

启动器与运行时上下文；
约定式自动加载机制；
统一中间件治理链路；
路由注册与兜底；
controller / service 分层与统一响应结构。

暂不做复杂插件生态、全量监控与完整测试平台，先保证内核稳定可跑。

1.2 启动生命周期（start）

elpis-core 的入口负责完成：

初始化 Koa 应用实例；
注入 app.options、app.baseDir、app.businessPath；
初始化环境能力 app.env；
按顺序加载 loader；
注册全局中间件；
注册路由；
启动监听。

核心原则：先装能力，再挂中间件，最后进路由。

1.3 Loader 能力拆分

当前已落地 loader：

extend-loader：加载扩展能力并挂到 app
middleware-loader：聚合中间件到 app.middlewares
config-loader：按环境加载并合并到 app.config
controller-loader：实例化并挂载到 app.controller
service-loader：实例化并挂载到 app.service
router-schema-loader：聚合到 app.routerSchema
router-loader：加载并挂载路由

收益非常直接：
新增模块时，只需按约定放文件，不再维护额外注册清单。

1.4 请求治理链路（已打通）

当前请求处理路径：

全局异常处理
API 签名校验
API 参数校验（AJV + JSON Schema）
路由分发
controller 编排
service 执行业务
统一响应返回

这条链路让治理逻辑前置、业务逻辑下沉，职责边界清晰，排障路径稳定。

1.5 当前目录边界

elpis-core/：框架内核（启动、加载、路由、环境）
app/extend/：扩展能力（如日志）
app/middleware/：中间件治理
app/router-schema/：接口参数约束
app/router/：路由层
app/controller/：请求编排层
app/service/：业务实现层

边界原则：框架负责通用能力，业务负责领域实现。

1.6 阶段成果与优化项

已完成成果

服务端微内核可运行；
自动加载机制可用；
请求治理链路成型；
基础分层落地。

下一步优化（Part 1 内核增强）

启动监听参数进一步规范化；
签名 key 配置化，避免硬编码；
参数校验链路副作用控制；
补齐 loader / middleware / router 核心测试。

Part 2：工程化（骨架，待更新）

2.1 目标

统一开发规范与质量门禁；
构建发布流程标准化；
配置管理环境化与分层化。

2.2 计划覆盖内容

dev/beta/prod 构建链路
lint/test/commit 规范
CI/CD 与回滚策略
日志与问题排查 SOP

2.3 当前状态

方案固化中
基线流程待落地
文档待补充

Part 3：领域模型架构（骨架，待更新）

3.1 目标

建立清晰领域边界；
降低跨模块耦合；
让业务规则可表达、可测试、可演进。

3.2 计划覆盖内容

应用层 / 领域层 / 基础设施层职责
实体、值对象、聚合、仓储模式
领域事件与状态流转

3.3 当前状态

领域划分进行中
模型约束待固化
示例代码待补充

Part 4：动态组件库（骨架，待更新）

4.1 目标

组件可配置、可组合、可复用；
页面搭建效率可规模化提升。

4.2 计划覆盖内容

组件协议（props/events/schema）
动态渲染与注册机制
版本兼容与主题体系

4.3 当前状态

协议设计中
渲染引擎待实现
组件资产待整理

Part 5：封装 npm 包（骨架，待更新）

5.1 目标

核心能力标准化输出；
多项目复用与版本治理。

5.2 计划覆盖内容

包拆分策略（core/plugins/utils）
API 稳定性与向后兼容
发布流程与 changelog 规范

5.3 当前状态

包结构设计中
发布策略待确定
文档模板待完善

Roadmap（持续更新）

结语

Elpis 第一阶段追求的不是“功能最全”，而是“演进最稳”。
后续我会按这 5 个部分持续更新，把它从“可运行”推进到“可规模化复用”。

欢迎交流你在全栈框架演进中最关注的问题：
是工程化治理、领域模型落地，还是组件与包复用体系？