大家好,我是Eluxjs的作者,Eluxjs是一套基于“微模块”和“模型驱动”的跨平台、跨框架『同构方案』,欢迎了解...
文前声明,以下推断和结论纯属个人探索,鉴于本人知识水平所限,谬误在所难免,恳请各位大佬不吝赐教...
Elux中的『微模块』是指在Web前端工程中,将代码和相关资源按照不同的业务功能
进行归类和模块化。
根据业务功能
进行模块化一直以来都是后端的普遍做法,而Web前端则通常都是按照UI界面的视图区块View
来进行模块化,这样的模块实际上只是Component组件
,不具备独立自治的能力。究其原因我想是因为在早期Web1.0的时代,前端的职能就是仅仅作为后端API数据的一个Render渲染器,所以前后端的视野和格局出现了分化,也导致很多人说前端根本无架构之说。
然而web生态发展到今天,浏览器越来越强大,赋能越来越多,甚至不亚于一个小型操作系统,这时候的Web前端早已不是当初简单的数据渲染器,状态管理、会话维持、数据持久化、文件缓存、通信协议...随着PWA、小程序、快应用的推广,WebAPP不再是瘦客户端,渐渐成长为大胖小子。
此时的我们应当跳出“渲染器”的井口,而从一个完整的软件工程来思考我们的前端架构,Web前端不只是一层View、一个GUI,我们需要回归到与后端一致的以业务领域
为驱动的模块化视角。
从开发角度来说:我们需要高内聚、低耦合
的松散结构体,而不是牵一发而动全身的巨石应用,这不管是对于开发、维护、还是后期渐进式重构,都至关重要。
前端Leader:经过一年多的迭代和人员变动,我们代码已经混乱不堪了,开发越来越吃力,必须要重构,否则玩不下去了! 产品经理:嗯,我理解,这里面也有很多是我们需求变更频繁引起的,我支持你们重构! 前端Leader:感谢大佬理解,那新需求先停下来,等我们重构好了再迭代吧? 产品经理:你们重构要多久? 前端Leader:产品这么复杂了,估计至少要3个月左右吧。 产品经理被吓出一身冷汗:大佬,你要3天还可以考虑,停下来3个月估计公司都要关门了... 前端Leader:可是产品这么复杂,几天时间完成重构是天方夜谭。 产品经理想了想:这样把,我每个迭代少安排几个需求,这样你们每个月就可以留几天时间重构了。 前端Leader:这可不是1+1=2的问题,而是0与1的问题,大佬你不了解! 产品经理:谁说我不了解,你们就不能渐进式重构吗? 前端Leader:...
此时如果我们的前端工程是基于“微模块”,一来可以轻松的找到“局部重构”的边界
,二来也可以通过维持“微模块”的对外接口来无极替换。
从产品角度来说:软件架构永远是服务于业务需求的。我们希望我们的产品能像搭积木一样按需组合
,可以快速包装出各种灵活多样的套餐,以满足客户越来越精细化的定制需求。
某个大型应用包含A,B,C,D,E,F,G等若干功能,原来一直是整体打包出售... 随着用户需求的多样化,有的用户仅需要部分功能,于是聪明的前端架构师“小李”利用时下流行的微前端技术, 将应用拆分成了的 3 个子应用: - 【基础应用】包含功能:A - 【子应用A】包含功能:B,C,D - 【子应用B】包含功能:E,F,G 这样等于有 3 个套餐可以供客户选择: - 套餐A:基础应用 + 子应用A - 套餐B:基础应用 + 子应用B - 套餐C:基础应用 + 子应用A + 子应用B 然而用户的需求越来越精细化,有的需要ABCD,有的需要ACEG,有的需要ABDF... 而且同一个功能可能还存在需求版本的不同,这让“小李”无可适从。
现在我们利用“微模块”来帮助小李解决问题:
C功能的某个版本
),E2(E功能的某个版本
),G 功能,我们单独为该客户创建一个聚合工程分支,安装相应版本的微模块:npm install A C@1 E@2 G
我们知道世界上有一款建站神器
wordpress
,曾经号称世界上50%的网站都是由它创建的,我认为它的成功秘诀就是社区模版机制和功能插件化,你要什么功能都总能找到“前端+后端”一起打包安装的插件,这也类似于“微模块”的概念。
通用业务代码
的理想决方案,对于跨端、跨平台复用业务逻辑
尤其有用。高内聚、低耦合
的工程结构。独立自治
的子域逻辑。从图中可以看到,每个微模块负责定义和维护自己领域内的事务,并且麻雀虽小,五脏俱全
,拥有独立的路由解析、状态管理、数据模型、控制器、视图、组件、资源、业务实体、API管理等等...总之,所有与自己领域相关的资源都被内聚到了一起。
以下是某巨石应用的SRC目录,其特点是以“文件职能”作为一级分类、“功能模块”作为次级分类:
├─ src │ ├─ api # API接口管理 │ ├─ assets # 静态资源文件 │ ├─ components # 全局组件 │ ├─ config # 全局配置项 │ ├─ enums # 项目枚举 │ ├─ hooks # 常用 Hooks │ ├─ language # 语言国际化 │ ├─ layout # 框架布局 │ ├─ routers # 路由管理 │ ├─ store # store │ ├─ styles # 全局样式 │ ├─ typings # 全局 ts 声明 │ ├─ utils # 工具库 │ ├─ views # 项目所有页面 │ ├─ App.vue # 入口页面 │ └─ main.ts # 入口文件
以下是Elux中基于微模块的SRC目录,其改进是将“功能模块”作为一级分类,“文件职能”作为次级分类:
src ├── modules │ ├── ModuleA │ │ ├── entities │ │ ├── assets │ │ ├── api │ │ ├── utils │ │ ├── language │ │ ├── components │ │ ├── views │ │ ├── model.ts │ │ └── index.ts │ │ │ ├── ModuleB │ ├── ModuleC
前端开发最终呈现的是UI界面,但这只是表象,支撑UI界面渲染和交互的是背后一系列state、model、controller等幕后英雄,它们根据自己所属不同领域被封装在各个微模块
中,UI既然与它们唇齿相依,必然也将跟随它们内聚在一起。
本质上说View就是一个Component,但我们从架构的思维来区分它们:
所以在“微模块”的架构中,丰富多彩的UI界面由一个个单一职责的View聚合
而成,每个View同样依据自身所解决的领域问题而被分散
在各个微模块中,这里面有几个注意点:
微模块
的原则是其解决的问题领域,而不是视觉上的几何空间。View可以在视觉上被拆装、聚合、嵌套,这并不影响它们所属微模块。不以视觉延伸和几何空间作为View的微模块归属原则:如下图所示,假设有一个View用来展示用户资料
,我们将其放在UserModule这个微模块中,称其为UserModule.DetailView
,但你发现其中又包含一个该用户发表文章的列表
,你当然可以把这个列表单独提取出来作为一个新的View。从视觉上来看,它似乎和用户资料是连在一起的,似乎可以和UserModule.DetailView
放在同一个微模块中;但我们从它解决的问题来看,它属于文章领域,而与用户领域关系并不大,所以我们最好将其放在ArticleModule中,称其为ArticleModule.ListView
Module Federation
,将微模块作为子应用独立部署,与时下流行的微前端类似。这种方式的优点是某子应用中的微模块更新时,依赖该微模块的其它应用无需重新编译,刷新浏览器即可动态获取最新模块;缺点是没有打包工具的整体编译与优化,代码和资源容易重复加载或冲突。从本意上来说,微模块只是一种工程结构和模块化方案,而微前端
只是它的一种应用场景之一。微模块架构不仅可以用来构建复杂的单体应用,也可以结合Module Federation
实现多子应用独立部署的“微前端”。
如果单独就微模块 + ModuleFederation
方式实现的微前端,与传统意义上的qiankun、icestark
等微前端方案相比,微模块方式胜在粒度更细、更灵活、更轻巧,而传统方式则胜在隔离性更好。
想到一个非常形象的比喻:
IFrame vs 微前端 vs 微模块
可类比于 进程 vs 线程 vs 协程
从左至右:越来越轻量化,隔离性逐渐变弱,灵活性逐渐增加。所以鱼与熊掌不可兼得,具体哪种方案最适合还得看不同的产品需求。
ActionBus
。高内聚、低耦合
的划分原则,也意味着微模块之间不会出现特别复杂的互动与交流(互动密切的微模块应当合并)。光练不说傻把式,光说不练假把式
,这里先把思路概念要说的说完,下面就要开始出实例了。先喝口水,请听下回分解...