关于前端模块化说到前端模块化，你可能第一时间想到cmd、amd、umd等前端模块化标准.这些是文件级模块，或者你会想到组件封装、npm包封装等，属于组件级模块化；或者你会想到将页面切割成许多独立的块，每个块是一个模块，属于视图级模块化；而我们今天要讨论的是业务功能层面的前端模块化。业务功能层面的前端模块化，对于后台开发人员来说是非常熟悉的。我们通常所说的“用户模块”、“订单模块”、“评论模块”，都是从业务功能的角度来划分的。随着前端承载的功能越来越重，现在已经不仅仅是一个视图的简单渲染，往往还包含大量的业务逻辑和状态，所以越来越多的前端项目也出现了模型、controllers、states等概念，如果前端的模块化仅仅停留在文件和组件层面，那么整个项目将变得难以维护和扩展。业务模块应该是一个高内聚、低耦合的整体封装。看了很多流行的前端工程结构，往往是这样的：├──src│├──assets│├──components│├──layouts│├──models//vuex或者dva，分为按业务功能分模块││├──user││├──order││└──comment│├──pages│├──services│├──utils可以在models（store）字段中看到，还是有按业务功能划分的模块，但是……仅限于机型。没有视图的单个模型模块有什么意义？这种模块化是否完整？能否独立开发？能不能灵活插拔？它可以水平扩展吗？一个完整的模块应该包含：一个处理抽象逻辑和状态的模型，以及一组显示模型的相关视图。注意：模型和视图是一对多的关系。其他一些组件和辅助资源应该归类在一个目录下，而不是分散在各个角落。独立开发时，我只需要有这个目录的修改权限，而不是整个项目。插拔模块时，只需要copy或del这个目录，而不用去挖掘每个目录去寻找相关文件……所以我期望的项目结构应该是这样的：├──src│├──assets//Commonresources│├──components//公共组件│├──utils//公共工具│├──modules//多个独立的业务模块│││││├──user//用户模块│││├──assets//私有资源│││├──components//私有组件│││├──utils//私有工具││├──model//model│││└──views//一个或多个视图│││├──page1│││├──page2│││├──list│││├──editor│││└──layout││││├──order//ordermodule│││├──assets//私有资源││├──components//私有组件│││├──utils//私有工具││├──model//模型│││└──views//一个或多个视图│││├──page1│││├──page2│││├──list│││├──editor│││└──layout│││││├──comment//评论模块│││├──...可以看到每个模块都有一个独立的目录结构，各种资源都是分的分为公共资源和模块私有资源。所有模块只依赖于公共资源。模块切割得非常干净。视图的模块化也将页面（视图）分为不同的模块。你可能会问：如果一个视图包含多个模块和内容，那么这个视图应该属于哪个模块？在这种情况下，我们需要将视图切割成多个具有更多单一功能的子视图。视图可以嵌套，不是吗？按需组合加载当客户要购买“文章模块”时，当然会为他将文章模块相关的代码和资源打包在一起。单独给他一个视图或模型是没有意义的，那样做是行不通的。.按需加载也是如此：按需加载应该是整个模块，而不是传统意义上的懒加载一个组件。因此，在工程打包时，应将整个模块文件夹下的所有代码打包成一个独立的bundle。包括视图、模型、组件和其他辅助代码。注意，外部封装模块按照“高内聚低耦合”的原则进行划分。模块之间的模块是松散的。模块内部应该封装大量的方法和接口，只在需要的时候暴露和导出。如果两个模块之间的联系特别紧密，是否需要考虑是否应该合并为一个模块？关于微前端，前端也开始思考和借鉴后端“微服务”的概念，希望能找到解决方案。让复杂的前端业务应用自治是一个好主意，但是如何实现还没有成熟的案例。但是，尽可能凝聚和隔离模块之间的关系是概念上的共识。我上面的解决方案只是思考和想法。当然，实现这个想法还有各种具体的方案，比如我的原创：medux系列框架，欢迎讨论：欢迎尝试跨平台的前端框架@medux结合案例：medux-react-admin
