框架与业务分离
======
按小型公司以及各人项目来说，框架与业务分离不是必须的：可分可不分。


框架代码
====
一切于业务逻辑不相关的代码，譬如loader，logger，cluster等基础设施，在业务代码中调用，但是与业务代码无关
等等，不经常改动的代码。

业务代码
===
controller，serivce，model(数据库),config,router,middleware(中间件)等等
这些会随着业务逻辑变来变去的代码


分离和不分离
====

第一

我们来先说说不分离，不分离的好处就是有bug马上就可以跑去框架中去改框架。
这对于需要快速开发的人来说，是极好的。

不过在JS，乃至动态类型的脚本届有一句话叫做：写时一时爽，改时火葬场。

很多同学都遇到过这样的场景，为了方便快速的开发，想怎么写怎么写，之后项目就进入了无法控制的地步。

再回过头改，我们可能要花几倍的时间去改都不一定能改明白。

所以，我建议，为了项目的发展，能拆分的一定要拆分，虽然麻烦了点，但是前期的麻烦，带来的就是后期的不掉头发。

第二

如果你只有一个项目，拆分框架的意义不明显，但是如果有一天，你需要开第二个项目，第三个项目，那你怎么办呢？

最直接想到的办法就是复制，改一改，粘贴。这么做不是不可以，但是就留下隐患。

比如，你在第一个项目跑起来后，第二第三个项目写一半的时候发现，框架有bug，那你就不得不改一次改三个项目。如果你有10个项目呢？

手工重复，代表着bugs!


框架拆分
====
说了那么多，我们来看看拆分出来的框架核心


```
.
├── README.md      --->框架的自描述
├── nodemon.json  
├── package-lock.json
├── package.json     --->框架的自描述
├── src            --->框架的代码
│   ├── app.ts    --->框架的启动
│   ├── base       --->controller和service的超类
│   │   ├── controller.ts
│   │   └── service.ts
│   ├── core.ts  --->框架的核心代码，继承，封装自koa
│   ├── loader.ts ---> loader类
│   ├── blueprint.ts    ---->路由蓝图
└── tsconfig.json
```

拆分之后，将框架代码发布到npm上，不过在此之前我们还是得考虑一些问题：

- 自动构建：需要一键构建出业务代码的目录，自动下载基础所需的依赖
- 开发自启动：我们已经将框架的启动隐藏在了框架代码里，因此，我们必须要提供一种能力，能让使用者快速重启开发
- 一键部署：自动启动cluster模块，提供多进程架构
- 框架的单元测试：把框架抽离出来以后，就要进行基本的单元测试，以保证以后加新功能时，老的功能不会出错




我们叫它burnjs
=====
教程走到这里，我们已经开发出了一套框架，作为应用程序的底层，为了方便以后的单独升级和维护，我把它抽离出来，就叫他burnjs吧。

抽离出来以后，我们要给框架配套一些基础设施，比如
- 自动化构建，部署
- 开发逻辑代码的保存自动重启
- 提供.d.ts描述文件
- 发布npm包

至于怎么上述流程如何走，我们将在附录中进行讲解：.........