前端简洁架构
原文链接：https://dev.to/bespoyasov/clean-architecture-on-frontend-4311
背景
- 公司一个历史项目是传统的项目结构（历史项目：最终走向都是堆叠，难以维护）
- 功能点多，逻辑复杂，不易扩展
架构介绍
架构介绍之前，先介绍下常见的
MVC分层框架
MVC架构是软件工程中常见的一种软件架构模式，该模式把软件系统（项目）分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。分层模型图如下
image.png
各分层的主要工作
模型
- 职责
模型负责处理应用程序的数据逻辑。 - 具体功能
封装应用程序的数据结构和业务规则。提供数据的读取、修改和存储等操作接口。处理数据的获取、处理、验证等具体逻辑。与数据存储层进行交互，实现数据的持久化。
视图
- 职责
视图负责用户界面的展示。 - 具体功能
显示模型中的数据给用户，以便用户可以看到应用程序中的信息。提供一种用户友好的界面，使用户能够与应用程序进行交互。根据模型的变化更新显示的内容，确保视图与数据保持同步。通常不处理数据的具体操作，而是通过控制器来调用模型进行处理。
控制器
- 职责
控制器负责处理用户的输入和协调模型与视图之间的交互。 - 具体功能
接收来自视图的用户输入，如按钮点击、表单提交等。根据用户的输入来调用相应的模型方法，处理数据的读取、修改等操作。更新模型中的数据，并通知视图进行相应的更新展示。处理用户输入的验证和错误处理，确保数据的正确性和一致性
前端简洁架构
简单介绍
是一种根据其与应用领域的密切程度来分离职责和部分功能的方式
简洁架构通常被称为三层架构 Domain（领域层 ）、Application（应用层）、Adapters（适配器层）
image.png
领域层
它是描述应用程序领域的实体和数据，以及用于转换数据的代码，并且实体和转换数据和外界是无关的
以商城为大背景，商城包含产品、订单、用户、购物车，以及更新其数据的功能。以添加商品到购物车为例，将物品添加到购物车的函数并不关心该物品到底是如何添加的：是由用户自己通过 "购买"按钮添加的，还是通过其它方式自动添加的。这些情况下，它都会接受该物品，并返回一个带有新增物品的更新后的购物车
应用层
领域的上一层就是应用层，这一层主要描述用户场景，事件发生之后的处理逻辑，可以解释为
应用层就是组合领域层提供的模型和转换函数以及三方接口 完成当前场景的逻辑
例如，"添加到购物车 "场景是一个用例。它描述了添加按钮被点击后的具体实现。
- 通过领域提供的纯函数，执行这个领域的转换，向购物车列表添加新商品
- 重新绘制用户界面
在应用层中，还有 端口（ports），即应用希望外部世界如何与之通信的规范。通常，一个端口是一个接口（interface），一个行为契约
端口 作为应用程序的期望和现实之间的 "缓冲区"。输入端口 表明应用程序希望如何被外部世界联系；输出端口 表明应用程序要如何与外部世界沟通，使其做好准备
适配器层
适配器在最外层，适配器需要把 不兼容的外部服务的API 变成 兼容应用层定义的API。
适配器是降低代码和三方服务代码之间耦合度的一个好方法。低耦合度减少了在更改其他模块时需要更改一个模块的需求。适配器通常被分为：
- 驱动型--向应用程序发送信号
- 被驱动型–接收来自应用程序的信号
依赖规则
三个分层有一个依赖规则：只有外层可以依赖内层，单向的，见下图
这么写的成本很高，所以某些时候你会偷懒打破这种依赖关系（最好在蔓延之前及时把问题代码调整回来）
- 循环依赖，模块A依赖B，B依赖C，C又依赖A（编译出问题，会造成死循环）
- 耦合度太高，模块之间的关系变得混乱
- 测试性差，用例不在纯净，必须模拟整个系统来测试一个小部分
- 会导致问题蔓延，回到屎山时代
image.png
添加购买商品示例
架构
image.png
实体之间的关系
image.png
设计领域
领域中的转换函数只依赖于领域的规则（在这里联想到了JPA：JPA是Java Persistence API的简称，中文名Java持久层API，是 Java 标准中的一套ORM规范，借助 JPA 技术可以通过注解或者XML描述【对象-关系表】之间的映射关系，并将实体对象持久化到数据库中，Spring Data JPA是一个 JPA 数据访问抽象。也就是说Spring Data JPA不是一个实现或 JPA 提供的程序，它只是一个抽象层，主要用于减少为各种持久层存储实现数据访问层所需的样板代码量）
image.png
而现在领域层和转换函数就是现在的抽象层，看一段JPA的代码
定义实体
image.png
提供查询接口
image.png
实体类 + 数据访问接口 类似于 领域 + 转换函数
回到正题：
当前场景存在的领域包括：
- 实体的数据类型：购物车、订单、产品、用户
- 数据转换函数（纯函数）
领域中的转换函数是依赖于领域的规则。例如：
- 购物车添加产品
- 创建订单
- ...
image.png
创建领域实体
领域中有以下模块：
- 订单
- 购物车
- 用户
- 产品
产品
image.png
用户
image.png
购物车
image.png
订单
image.png
转换函数
上面设计领域时提到的创建的转换函数纯函数：仅针对当前实体，没有副作用，更容易工作和调试，例如：
购物车添加产品
image.png
产品计算价格
image.png
创建订单
image.png
设计应用层
用例
应用层包含用例（单个功能的具体实现）。
例如：
- 添加产品到购物车
- 创建订单
同时在应用层中，有一些端口-接口用于与外部世界进行通信（类似于 微服务开发中 FeignClient，服务与服务之间的数据通信，定义了一个接口，然后就可以拿到实例,并且调用其他服务的接口，见下图，定义了三方的接口）
image.png
回到正题，应用层主要是逻辑的实现，因为我们的领域层是相对纯净的，不存在和外界交互，所以应用层介于领域层和外界中间，保证领域的纯净，又能实现外界交互
image.png
在“将产品添加到购物车”用例中，这看起来像：
- 首先，选中产品点击按钮；
- 调用添加到购物车用例
- 调用纯函数添加到购物车，返回购物车列表
- 更新购物车列表
整个过程是单向数据流，，外界点击添加按钮 =》应用层添加产品到购物车的用例（调用领域纯净函数更新购物车列表）
应用层是一个媒介，链接领域和外界，保持各自的独立不受影响
image.png
端口
添加控件是我们的一个领域纯函数，其他的服务都是外部服务，而前面我们已经定义了外部服务的接口，所以外部服务API必须适应我们的需求，但是外部服务可能随时变化的，所以衍生出适配器
比如我们需要的外部服务：
- 创建一个新的订单。
- 订单付款。
- 通知
- 清除购物车
- 更新购物车
image.png
目前这里都是接口的定义，应用层将会使用他们的定义，具体实现在适配层
设计适配层
- API请求模块
- API回应到应用层的适配器和转换器
- ...等
image.png
正如应用所言，通常情况下外部服务都不能满足需求并且业务经常变化。因此，我们使用适配器来调整外部接口以满足我们的需求 （例如上文提到的微服务场景下的FeignClient）
总的来说 适配器层就是为应用层使用的外部服务接口的适配（图1: 订单支付API适配，图2 通知API适配）
image.png
image.png
分层如何区分
领域在domain/目录下，应用层在application/，适配器在services/
image.png
对比 MVC架构
- 模型（models）通常是领域实体（domian）
- 控制器（controllers）是领域转换和应用层（application）
- 视图（view）是驱动适配器（adapters）
可以说是非常相似，有助于我们区分分层
优势和成本
架构对比
image.png
优势
- 领域分离
所有的主要应用功能都被隔离并收集在一个地方–领域。领域中的功能是独立的，它更容易测试，有助于新开发人员掌握应用程序功能，有助于更快地寻找从业务语言到编程语言的 "翻译"中的错误和不准确之处
- 独立用例
用例代码也变得可测试和可扩展。
- 可替换的三方服务
由于适配器的存在，外部服务变得可替换。只要我们不改变接口，哪个外部服务实现了这个接口并不重要，这样一来，外层业务无论如何变化，并不会影响底层的设计
成本
- 时间成本
时间成本变高，每个场景要定义接口，实现用例，再写适配层，直接调用三方接口一定是比写适配器快的
- 冗余成本
小项目不适合，代码实现繁琐，简洁架构优势在于解决项目未来的维护和扩展
- 门槛
对于新人的学习门槛要高一点
- 代码数量
简洁架构会增加前端项目最终打包的代码量。我们给浏览器的代码越多，它需要下载、解析和解释的就越多，深有体会，这是需要优化的
- 架构腐化
随着时间和版本的迭代，可能会偷懒打破这种三层依赖关系，导致问题蔓延，发生架构异味，失去三层架构的初衷
