一个企业级骨架
=====
通过上述几个步骤和规范，我们就定制了一套初级的企业级框架。虽然是初级版本，但是相比于基础koa框架来说，已经强大得很多了。


项目目录的规范总结
====

```
.
├── dist    ---->构建之后的文件夹
├── nodemon.json
├── package-lock.json
├── package.json
├── src    ---->源代码文件
│   ├── app.ts   ---->app的启动
│   ├── config   ---->配置的目录
│   │   ├── config.default.ts   --->公共配置
│   │   ├── config.dev.ts       --->开发配置
│   │   └── config.pro.ts       --->线上配置
│   ├── controller  ---->逻辑控制器的代码目录
│   │   ├── base.ts
│   │   └── user.ts
│   ├── loader.ts  ---->加载器
│   ├── router.ts   ---->路由器集合
│   └── service   ---->业务代码的目录
│       └── check.ts
└── tsconfig.json
```

概念总结
=====
经过上一章内容的完成，我们已经成功的引入了三组概念

- controller，专门处理业务的控制流程，尽量不出现任何的业务逻辑，而且controller必须放在controller文件夹中，否则无法读取到

- router，路由的设置，我们全部放在了routers.js中，集中化管理，使得我们的路由、Http方法不会因为散落各地而难以查找

- service ，业务逻辑与控制器完全分离，不依赖于控制器，能够方便你的逻辑复用和单元测试

- 全自动按目录加载：所有的代码，类，都按照规范写好后，就能够全自动的导入到项目中，无需人力再进行对这种无用但是又容易出错的操作进行乱七八糟的维护，极大的提升了我们开发业务代码的效率。

或许聪明的你已经发现了这么做的好处：**超出控制范围的代码框架连启动都无法启动，比如有人不爽，想到处写业务逻辑，boom，爆炸**。

**又比如，有人想到处乱写router，boom爆炸。**

由此，我们得出了一个深刻的道理：

**一定限制和约束，是企业级（包括个人）大项目所必须的**