注:来源于哲玄实践全栈课程
为什么要有elpis-core
elpis-core可以用来约束规则，例如一个开发团队如果没有一个规则来进行约束，那么代码的可阅读性，可维护性会变的非常低，这种情况肯定不是一个合格的开发团队，而elpis-core就是用来解决这种问题的，来生成一个硬性的规则来约束大家 *例如：路由就存放在router文件夹 中间件就存放在middleware文件夹 路由的逻辑处理就存放在controller等等 *
router => 路由
router-schema => 路由规则
config => 配置项
middleware => 中间件
controller => 处理请求以及响应
service => 执行业务逻辑
extend => 扩展 (连接数据库 提供日志功能)
elpis-core的实现原理
elpis-core是基于nodejs和Koa来搭建的，当文件启动的时候，我们会为上述每个模块都创建一个loader，这些loader会批量的去处理加载文件中的内容并挂载到Koa的实例上，方便后续引用
模块存放位置 经过loader编译处理 存放koa实例上
app/router/**.js => routerLoader => app.router.**
app/middleware/**.js => middlewareLoader => app.middleware.**
app/controler/**.js => controllerLoader => app.controller.**
app/service/**.js => serviceLoader => app.service.**
config/**.js => configLoader => app.config.**
extend/**.js => extendLoader => app.**
loader的挂载顺序
对于loader的挂载顺序其实除了config和router外没有特别固定的次序，我们只要保证在执行任意一个loader的时候，其它loader都已经执行完毕挂载到koa实例上，这样就不会导致在loader依赖其它模块的时候对其引用出现为空还没挂载的情况。 当然如果为了代码的逻辑性以及可阅读性我们就可以按照发送请求后 每个loader执行的顺序来进行挂载，在这之间middleware会分别在请求阶段以及响应阶段执行(洋葱圈模型)，以下是一个流程图
graph TD
A[API请求/页面请求] --> B[router路由/router-schema]
B --> C[middleware中间件]
C --> D[中间件1]
D --> E[中间件2]
E --> F[controller]
F --> G[service]
G --> H[中间件1 - 响应阶段]
H --> I[中间件2 - 响应阶段]
I --> J[API响应/页面响应]
