前端微服务化(一)：初探
微前端产生的原因
一个团队负责的项目（不管前后端还是全栈），随着时间的推移，会极大的可能发生下面的变化。为了这些变化，各种繁琐的组合，开分支，打tag等造成后期的维护成本增加，代价随之越来越大。随着互联网的发展，一种将多个不同的服务集中在一个大平台上统一对外开放的概念逐渐为人熟知，越来越多与云相关或不相关的中后台管理系统或企业级信息系统曾经或开始采用了这种「统一平台」的形式。同时，前端领域保持着高速发展，早期的 jQuery+Backbone+Bootstrap 的 MVC 解决方案支撑起了业务相当长的一段时间；后来，Angular、Ember 等 MVVM 框架开始崭露头角，前后端分离和前端组件化的思想在此时达到了鼎盛期。而在国内，Vue 框架凭着其简洁易懂的 API 和出色的周边生态支持独领鳌头，越来越多的中小型企业和开发者们开始转向 Vue 阵营；与此同时，在设计上独树一帜的纯 View 层框架 React 开始兴起，其充满技术感的 Diff DOM 思想吸引了大批开发者，成为各大技术社区最火爆的话题，其周边生态也随之快速发展，成为了各大公司搭建技术栈时的首选框架。
目前的前端领域，单页面应用（SPA）大行其道。而随着时间的推移以及应用功能的丰富，这些应用变得越来越庞大也越来越难以维护。于是“微前端”这一概念应运而生。
“微前端”出自2016 年的 ThoughtWorks 技术雷达，指 将项目拆分成一个个可独立运行、独立开发、独立部署的前端微应用，这些微应用可以并行开发、共享组件 。
什么是微前端
微前端背后的理念是将一个网站或者 Web App 当成特性的组合体，每个特性都由一个独立的团队负责。每个团队都有擅长的特定业务领域或是它关心的任务。这里，一个团队是跨职能的，它可以端到端，从数据库到用户界面完整的开发它所负责的功能。然而，这个概念并不新鲜，过去它叫针对垂直系统的前端一体化或独立系统。不过微前端显然是一个更加友好并且不那么笨重的术语。
微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。
什么要用微前端
任何一种技术或者概念都有其适用场景，微前端也不例外。 针对中小型的项目，使用微前端反而会将事情复杂化 ，因为微前端对项目的开发并不友好。
项目技术栈过于老旧,相关技能的开发人员少,功能扩展吃力,重构成本高,维护成本高.
项目过于庞大,代码编译慢,开发体差,需要一种更高维度的解耦方案.
单一技术栈无法满足你的业务需求
微服务化后端前后端对比
后端微服务化的优势复杂度可控:
1).体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
2).独立部署: 由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
3).技术选型灵活: 微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。
4).容错: 当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。
5).扩展: 单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。
前端微服务化后的优势
1)复杂度可控: 每一个UI业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
2)独立部署: 每一个模块可单独部署,颗粒度可小到单个组件的UI独立部署,不对其他模块有任何影响。
3)技术选型灵活: 也是最具吸引力的,在同一项目下可以使用如今市面上所有前端技术栈,也包括未来的前端技术栈。
4)容错: 单个模块发生错误,不影响全局。
5)扩展: 每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗；
前端微服务给我们带来什么
最小程度独立开发
细粒度开发，不论是一个大项目还是小项目，均可以拆分多个大小不一的小模块（app）
模块根据具体的业务场景，可进行打散和重新组合
模块与项目的关系可以是一对多（公用模块）或一对一 （单业务）
最小程度独立部署
一个单体的前端应用最大的问题是构建出来的前端资源文件（js,css)太大，若使用独立开发，则这些文件可以拆分成多个文件
可以按照不同的环境部署（如 CDN)
轻耦合
独立开发中，SPA的应用开发中DOM即API
前后端数据彻底分离
数据与业务分离
技术无关
我们必须组合app模块，若技术无关，那app可能是 angular, react, vue 等构成.
使用后端模板引擎插入 HTML（渐进式从后端进行加载
使用 IFrame 隔离运行时（PostMessage)
客户端 JavaScript 异步加载
WebComponents 整合所有功能模块
Single-SPA/Micro Frontends/Mosaic/Mooa/single-spa-angular-cli【推荐】
数据交互使用CustomEvent交互
不同模块的数据使用共享事件总线
使用不同的服务器缓存（squid, varnish, nginx），整合不同的模块
提高开发效率，减少开发时间
微前端背后的核心理念
1.技术无关
每一个团队在选择和升级他们的技术栈时应该能够做到不需要和其他团队进行对接。Custom Elements 是一个隐藏实现细节的非常好的方法，同时能够对外提供一个统一接口。
2.隔离团队代码
即使所有的团队都使用同样的框架，也不要共享一个运行时。构建独立的应用，不要依赖于共享状态或全局变量。
3.建立各团队的前缀
当隔离已经不可能时要商定一个命名规范。对 CSS、Events、Local Storage 和 Cookie 建立命名空间来避免碰撞并声明所有权。
4.本地浏览器特性优先于自定义 API
采用浏览器事件进行数据沟通而不是构建一个全局的发布者-订阅者系统。如果你确实需要构建一个跨团队的 API，那就确保它越简单越好。
5.构建自适应网站
即使 JavaScript 执行失败或是根本没有执行，你的特性也应该是能够使用的。采用通用渲染或渐进式增强来提高可感知的性能。
面临的问题与挑战
我们如何实现在一个页面里渲染多种技术栈?针对于老系统，如何实现从 Backbone 技术栈到 React 技术栈或 Vue 技术栈的平滑
不同技术栈的独立模块之间如何通讯?
如何通过路由渲染到正确的模块?
在不同技术栈之间的路由该如何正确触发?
项目代码别切割之后,通过何种方式合并到一起?
我们的每一个模块项目如何打包?
前端微服务化后我们该如何编写我们的代码?
独立团队之间该如何协作?
怎样将不同业务子系统集中到一个大平台上，统一对外开放？
如何给不同用户赋予权限让其能够访问平台的特定业务模块同时禁止其访问无权限的业务模块？
如何快速接入新的子系统，并对子系统进行版本管理，保证功能同步？## 前端微服务化(一)：初探
微前端产生的原因
一个团队负责的项目（不管前后端还是全栈），随着时间的推移，会极大的可能发生下面的变化。为了这些变化，各种繁琐的组合，开分支，打tag等造成后期的维护成本增加，代价随之越来越大。随着互联网的发展，一种将多个不同的服务集中在一个大平台上统一对外开放的概念逐渐为人熟知，越来越多与云相关或不相关的中后台管理系统或企业级信息系统曾经或开始采用了这种「统一平台」的形式。同时，前端领域保持着高速发展，早期的 jQuery+Backbone+Bootstrap 的 MVC 解决方案支撑起了业务相当长的一段时间；后来，Angular、Ember 等 MVVM 框架开始崭露头角，前后端分离和前端组件化的思想在此时达到了鼎盛期。而在国内，Vue 框架凭着其简洁易懂的 API 和出色的周边生态支持独领鳌头，越来越多的中小型企业和开发者们开始转向 Vue 阵营；与此同时，在设计上独树一帜的纯 View 层框架 React 开始兴起，其充满技术感的 Diff DOM 思想吸引了大批开发者，成为各大技术社区最火爆的话题，其周边生态也随之快速发展，成为了各大公司搭建技术栈时的首选框架。
目前的前端领域，单页面应用（SPA）大行其道。而随着时间的推移以及应用功能的丰富，这些应用变得越来越庞大也越来越难以维护。于是“微前端”这一概念应运而生。
“微前端”出自2016 年的 ThoughtWorks 技术雷达，指 将项目拆分成一个个可独立运行、独立开发、独立部署的前端微应用，这些微应用可以并行开发、共享组件 。
什么是微前端
微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。
什么要用微前端
任何一种技术或者概念都有其适用场景，微前端也不例外。 针对中小型的项目，使用微前端反而会将事情复杂化 ，因为微前端对项目的开发并不友好。
项目技术栈过于老旧,相关技能的开发人员少,功能扩展吃力,重构成本高,维护成本高.
项目过于庞大,代码编译慢,开发体差,需要一种更高维度的解耦方案.
单一技术栈无法满足你的业务需求
微服务化后端前后端对比
后端微服务化的优势复杂度可控:
1).体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
2).独立部署: 由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
3).技术选型灵活: 微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。
4).容错: 当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。
5).扩展: 单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。
前端微服务化后的优势
1)复杂度可控: 每一个UI业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
2)独立部署: 每一个模块可单独部署,颗粒度可小到单个组件的UI独立部署,不对其他模块有任何影响。
3)技术选型灵活: 也是最具吸引力的,在同一项目下可以使用如今市面上所有前端技术栈,也包括未来的前端技术栈。
4)容错: 单个模块发生错误,不影响全局。
5)扩展: 每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗；
前端微服务给我们带来什么
最小程度独立开发
细粒度开发，不论是一个大项目还是小项目，均可以拆分多个大小不一的小模块（app）
模块根据具体的业务场景，可进行打散和重新组合
模块与项目的关系可以是一对多（公用模块）或一对一 （单业务）
最小程度独立部署
一个单体的前端应用最大的问题是构建出来的前端资源文件（js,css)太大，若使用独立开发，则这些文件可以拆分成多个文件
可以按照不同的环境部署（如 CDN)
轻耦合
独立开发中，SPA的应用开发中DOM即API
前后端数据彻底分离
数据与业务分离
技术无关
我们必须组合app模块，若技术无关，那app可能是 angular, react, vue 等构成.
使用后端模板引擎插入 HTML（渐进式从后端进行加载
使用 IFrame 隔离运行时（PostMessage)
客户端 JavaScript 异步加载
WebComponents 整合所有功能模块
Single-SPA/Micro Frontends/Mosaic/Mooa/single-spa-angular-cli【推荐】
数据交互使用CustomEvent交互
不同模块的数据使用共享事件总线
使用不同的服务器缓存（squid, varnish, nginx），整合不同的模块
提高开发效率，减少开发时间
面临的问题与挑战
我们如何实现在一个页面里渲染多种技术栈?针对于老系统，如何实现从 Backbone 技术栈到 React 技术栈或 Vue 技术栈的平滑
不同技术栈的独立模块之间如何通讯?
如何通过路由渲染到正确的模块?
在不同技术栈之间的路由该如何正确触发?
项目代码别切割之后,通过何种方式合并到一起?
我们的每一个模块项目如何打包?
前端微服务化后我们该如何编写我们的代码?
独立团队之间该如何协作?
怎样将不同业务子系统集中到一个大平台上，统一对外开放？
如何给不同用户赋予权限让其能够访问平台的特定业务模块同时禁止其访问无权限的业务模块？
如何快速接入新的子系统，并对子系统进行版本管理，保证功能同步？
什么是现代化前端应用
在介绍中我使用了措辞“构建一个现代化前端应用”，让我们先给出一些这个术语有关的设定。
从一个更广泛的角度来看，Aral Balkan 曾写过一个相关的博客，他把这个概念叫做文档-应用连续统一体。他提出了一个滑动比例尺的概念，在比例尺的最左边是一个网站，由静态文档构成，通过链接相互连接；最右边是一个纯行为驱动的，几乎没内容的应用程序，比如在线图片编辑器。
如果你把你的项目定位在这个范围的左侧，那在 Web 服务器级别的集成会比较合适。在这个模型中，服务器会收集页面中各个组件的内容并将其 HTML 字符串连接起来返回给用户。内容更新则采用从服务端重新加载的方式或者通过 ajax 进行部分替换。Gustaf Nilsson Kotte 针对这个主题写过一篇综合性的文章。
当用户界面需要提供及时反馈时，即使采用不可靠连接，一个纯粹的服务端渲染网站也不够用。为了实现 Optimistic UI 或 Skeleton Screens 这样的技术你需要在设备本身对 UI 进行更新。Google 提出的 PWA 巧妙的描述了这种兼顾各方的做法（渐进增强），同时提供 App 一样的性能体验。这种类型的应用在上面的比例尺中位于文档-应用连续统一体中间的某个地方。在这里纯粹的服务端方案已经不再够用，我们必须将主要逻辑放到浏览器中，这正是本文会重点描述的。
DOM 就是 API
Custom Element
自定义元素 Custom Elements 面向 Web 组件规范中互操作方面，在浏览器中是一个适用于功能集成的基本元素。每个团队采用自己选择的 Web 技术构建他们的组件，并将它们封装到一个 自定义元素 中(比如 )。这个特定元素的 DOM 声明(标签名、属性和事件)对于其他团队来说体现为一个协定或者叫公共 API。这样做的好处是其他人可以使用这个组件及其功能而不需要知道实现细节，他们只需要能够和 DOM 交互即可。
但仅仅自定义元素是不能满足解决方案的所有需求的。为了处理渐进增强、通用渲染或路由我们还需要软件的其他部分。
本文分为两部分。首先我们会介绍页面组合(Page Composition) —— 如何使用不同团队提供的组件组合成一个页面。然后我们会给出一些示例展示客户端页面转化(Page Transition)的实现。
页面组合
除了采用不同框架编写的客户端或服务端代码集成，还有很多副主题需要讨论：隔离 js的机制、规避 CSS 冲突、按需加载资源、不同团队共享公共资源、处理数据获取和思考提供给用户的加载状态。我们将会依次讨论这些主题。
浏览器支持
采用了 Custom Element 规范 V1 版，目前已经在 Chrome, Safari 和 Opera 中得到支持。但是通过 document-register-element 这个轻量级且经过大量测试的 polyfill 可以让该特性在所有浏览器中运行。在底层，它使用了广泛支持的 Mutation Observer API，所以并没有在背后使用 DOM 树监听这种侵入式的 hack 方法。
框架兼容性
因为自定义元素 Custom Element 是一个 Web 标准，所有的主流 JavaScript 框架都支持，比如 Angular、React、Preact、Vue 或 Hyperapp。但深入到细节时，就会发现有些框架依然存在实现上的问题。可以访问 Custom Elements Everywhere 这个兼容性测试套件，Rob Dodson 把没有解决的问题都高亮显示了。
子父元素或兄弟元素通信 / DOM 事件
对于所有的交互来说从上至下传递属性是不够的。
组件和组件通信的效果他们可以构建一种内建的 JavaScript API 进行通信。但这样就需要组件实例之间相互了解，同时也违背了隔离的原则。
一种更加干净的方法是采用发布者订阅者机制：一个组件可以发布信息，其他组件则订阅指定的主题(topic)。幸运的是浏览器内建了这个特性，这也正是 click、 select、 mouseover 等浏览器事件的工作机制。除了这些本地事件，还有一种可能性是通过 newCustomEvent(…) 来创建更加高级别的事件。事件总是绑定到它们创建或者分配的 DOM 节点上，大部分本地事件也支持冒泡的特性，这让监听 DOM 中特定子树节点的所有事件成为可能。如果你想要监听页面上的所有事件，将事件监听器附加到 window 元素上就 OK 了
服务端渲染 / 通用渲染
在浏览器中采用自定义元素 Custom Elements 来集成组件是个绝好的做法。但实际在构建一个 Web 中可访问的站点时，很可能是初次加载性能才是关键点，在所有的 JS 框架全部加载并执行之前用户只会看到白屏。另外，还有一个值得思考的是如果 JavaScript 执行失败或者被阻塞时网站会发生什么。Jeremy Keith 在他的 ebook/播客 Resilient Web Design 中解释了这个问题的重要性。所以能够在服务端渲染核心内容才是关键。不幸的是 Web 组件规范根本没有讨论服务端渲染。JavaScript 没有，Custom Elements 也没有。
微前端的几种实现框架
Single-SPA
优点：跨技术栈、
缺点：粒度不够小，与其叫它微前端不如称其为微应用，因为它针对的是页面级的，通过管理路由整合其它应用；
每个子应用需要满足约定好的方式进行开发，不便对原有项目进行改造
Project Mosaic
优点：完全细粒度到组件
缺点：整体非常复杂
Open-Components
优点：细粒度到组件
缺点：需要部署registy库
通过约定方式发布组件到registry中，客户端直接使用发布的组件地址调用；
个人认为这种方式与发布到npm，然后加载umd包的方式没有太大区别，前者在发布时貌似处理了umd包依赖冗余的问题。
如何设计微前端架构
就当前而言，要设计出一个微前端应用不是一件容易的事——还没有最佳实践。在不同的落地案例里，使用的都是不同的方案。出现这种情况的主要原因是，每个项目所面临的情况、所使用的技术都不尽相同。为此，我们需要了解一些基础的微前端模式。
架构模式
微前端应用间的关系来看，分为两种：基座模式（管理式）、自组织式。分别也对应了两者不同的架构模式：
基座模式（管理式）
通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。
自组织模式
应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。
通过上面两个对比， 基座模式实施起来比较方便，方案上便也是蛮多的。
而不论种方式,都需要提供一个查找应用的机制，在微前端中称为服务的注册表模式。和微服务架构相似，不论是哪种微前端方式，也都需要有一个应用注册表的服务，它可以是一个固定值的配置文件，如 JSON 文件，又或者是一个可动态更新的配置，又或者是一种动态的服务。它主要做这么一些内容
a)应用发现:让主应用可以寻找到其它应用
b)应用注册:即提供新的微前端应用，向应用注册表注册的功能
c)第三方应用注册:即让第三方应用，可以接入到系统中
d)访问权限等相关配置
应用在部署的时候，便可以在注册表服务中注册。如果是基于注册表来管理应用，那么使用基座模式来开发比较方便
设计理念
中心化：应用注册表,这个应用注册表拥有每个应用及对应的入口。在前端领域里，入口的直接表现形式可以是路由，又或者对应的应用映射
标识化应用:我们需要一个标识符来标识不同的应用，以便于在安装、卸载的时候，能寻找到指定的应用。一个简单的模式，就是通过康威定律来命名应用
应用生命周期管理
高内聚，低耦合
生命周期
前端微架构与后端微架构的最大不同之处，也在于此——生命周期。微前端应用作为一个客户端应用，每个应用都拥有自己的生命周期：
Load:决定加载哪个应用，并绑定生命周期
bootstrap：获取静态资源
Mount：安装应用，如创建 DOM 节点
Unload：删除应用的生命周期
Unmount：卸载应用，如删除 DOM 节点、取消事件绑定
这部分的内容事实上，也就是微前端的一个难点所在，如何以合适的方式来加载应用——毕竟每个前端框架都各自不同，其所需要的加载方式也是不同的。当我们决定支持多个框架的时候，便需要在这一部分进入更细致的研究。
如何去拆分应用
技术方式
路由分发式:通过 HTTP 服务器的反向代理功能，来将请求路由到对应的应用上。
前端微服务化:在不同的框架之上设计通讯、加载机制，以在一个页面内加载对应的应用。
微应用:通过软件工程的方式，在部署构建环境中，组合多个独立应用成一个单体应用。
微件化:开发一个新的构建系统，将部分业务功能构建成一个独立的 chunk 代码，使用时只需要远程加载即可。
前端容器化:通过将 iFrame 作为容器，来容纳其它前端应用。
应用组件化:借助于 Web Components 技术，来构建跨框架的前端应用。
实施的方式虽然多，但是都是依据场景而采用的。有些场景下，可能没有合适的方式；有些场景下，则可以同时使用多种方案。
路由分发式
路由分发式微前端，即通过路由将不同的业务分发到不同的、独立前端应用上。**其通常可以通过 HTTP 服务器的反向代理来实现，又或者是应用框架自带的路由来解决
路由分发式的架构应该是采用最多、最容易的 “微前端” 方案
前端微服务化
前端微服务化，是微服务架构在前端的实施，每个前端应用都是完全独立（技术栈、开发、部署、构建独立）、自主运行的，最后通过模块化的方式组合出完整的前端应用.
采用这种方式意味着，一个页面上同时存在二个及以上的前端应用在运行。而路由分发式方案，则是一个页面只有唯一一个应用。
组合式集成：微应用化
微应用化，即在开发时，应用都是以单一、微小应用的形式存在，而在运行时，则通过构建系统合并这些应用，组合成一个新的应用。
微应用化更多的是以软件工程的方式，来完成前端应用的开发，因此又可以称之为组合式集成。对于一个大型的前端应用来说，采用的架构方式，往往会是通过业务作为主目录，而后在业务目录中放置相关的组件，同时拥有一些通用的共享模板。
微件化
微件（widget），指的是一段可以直接嵌入在应用上运行的代码，它由开发人员预先编译好，在加载时不需要再做任何修改或者编译。**而微前端下的微件化则指的是，每个业务团队编写自己的业务代码，并将编译好的代码部署（上传或者放置）到指定的服务器上，在运行时，我们只需要加载相应的业务模块即可。对应的，在更新代码的时候，我们只需要更新对应的模块即可。
在非单面应用时代，要实现微件化方案，是一件特别容易的事。从远程加载来对应的 JavaScript 代码，在浏览器上执行，生成对应的组件嵌入到页面的相应部分。对于业务组件也是类似的，提前编写好我们的业务组件，当需要对应的组件时再响应、执行。
前端容器化之 iframe
iframe 作为一个非常 “古老” 的，人人都觉得普通的技术，却一直很管用。它能有效地将另一个网页/单页面应用嵌入到当前页面中，两个页面间的 CSS 和 JavaScript 是相互隔离的——除去 iframe 父子通信部分的代码，它们之间的代码是完全不相互干扰的。iframe 便相当于是创建了一个全新的独立的宿主环境，类似于沙箱隔离，它意味着前端应用之间可以相互独立运行
前端容器化之 Web Components
Web Components 是一套不同的技术，允许开发者创建可重用的定制元素（它们的功能封装在代码之外），并且在 web 应用中使用它们
目前困扰 Web Components 技术推广的主要因素，在于浏览器的支持程度。在 Chrome 和 Opera 浏览器上，对于 Web Components 支持良好，而对于 Safari、IE、Firefox 浏览器的支持程度，并没有那么理想。
应用微化架构
应用微化架构，是一种开发时整体，构建时拆分，运行时分离的前端架构模式。即应用微化架构从一份代码中，构建出适用于不同环境的多套目标代码。
构建时拆分架构
代码删除架构:以删代码的方式，来形成每个前端应用。
微前端准备式架构:即，随时可以拆分为多个前端应用。
由于它与微应用化的相似性，我们将它与微应用化做一个对比。它与微应用化不同的是，应用微化是在构建时对应用进行拆分，而非在本地模式下对应用拆分。相似的是，它也是基于构建系统的应用拆分方式。由于它与微应用化的相似性，我们将它与微应用化做一个对比。它与微应用化不同的是，应用微化是在构建时对应用进行拆分，而非在本地模式下对应用拆分。相似的是，它也是基于构建系统的应用拆分方式。
微应用化，是一个随时可合并式架构。而应用微化，则是一个随时可拆分式架构。
它不仅仅是一个适合于前端的架构模式，也是一适用于后端的架构模式
整洁前端架构
Clean Architecture 是由 Robert C. Martin 在 2012 年提出的架构模式。它具有这么一些特点：框架无关性、可被测试、UI 无关性、数据库无关性、外部机构（agency）无关性。
对于前端架构来说，Clean Architecure 实际上是：Clean Architecture + MVP + 组件化。
这种架构模式特别适合于：组织内即写前端又同后端的团队。它易于映射前后端 API，且可以使用 usecase 作为防腐层。
不得不提及的是，对于小规模的团队来说，它带来的弊端可能会远远大于好处——带来大量冗余的代码。尽管通过 Angular Schematics 可以通过参数来生成代码，但是这种分层架构地于简单的应用来说，还是过于复杂、难以上手。对于不写测试的项目来说 ，usecase 也不能带来它们所承诺的好处