关于前端模块化

• 说到前端模块化，你马上想到的可能就是 cmd、amd、umd 等前端模块化标准，这些是属于 文件级别的模块化 ；
• 或者你会想到 component 的封装、npm 包的封装等等，这些属于 组件级别的模块化 ；
• 或者你会想到将页面切割成很多独立的区块，每个区块是一个模块，这些属于 视图级别的模块化 ；
• 而今天要探讨的是的 业务功能级别前端模块化 。

业务功能级别前端模块化在后台开发人员眼中再熟悉不过了，我们通常说的"用户模块","订单模块","评论模块"等都是从业务功能视角来划分的。随着前端承载的功能越来越厚重，现在已经不只是简单渲染一个视图而已，它往往也包含很多的业务逻辑和状态，所以越来越多的前端工程中也出现了 model、controller、states 等概念，如果前端模块化仅仅停留在文件、组件级别，那么整个工程将变得难以维护和拓展。

业务模块应当是高内聚、低耦合的整体封装

看了很多时下流行的前端工程结构，往往是这样：

├── src
│   ├── assets
│   ├── components
│   ├── layouts
│   ├── models //vuex或者dva，按业务功能划分模块
│   │     ├── user
│   │     ├── order
│   │     └── comment
│   ├── pages
│   ├── services
│   ├── utils
复制代码

可以看到，在 models(store)这个领域，还是有按照业务功能划分了模块，但是...也仅限于 models 而已，脱离 view，单纯一个 model 模块有什么意义？这样的模块化完整吗？能独立开发吗？能灵活插拔吗？能横向扩展吗？