原文链接：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

优势

• 领域分离

所有的主要应用功能都被隔离并收集在一个地方–领域。领域中的功能是独立的，它更容易测试，有助于新开发人员掌握应用程序功能，有助于更快地寻找从业务语言到编程语言的 "翻译"中的错误和不准确之处

• 独立用例

用例代码也变得可测试和可扩展。

• 可替换的三方服务

由于适配器的存在，外部服务变得可替换。只要我们不改变接口，哪个外部服务实现了这个接口并不重要，这样一来，外层业务无论如何变化，并不会影响底层的设计

成本

• 时间成本

时间成本变高，每个场景要定义接口，实现用例，再写适配层，直接调用三方接口一定是比写适配器快的

• 冗余成本

小项目不适合，代码实现繁琐，简洁架构优势在于解决项目未来的维护和扩展

• 门槛

对于新人的学习门槛要高一点

• 代码数量

简洁架构会增加前端项目最终打包的代码量。我们给浏览器的代码越多，它需要下载、解析和解释的就越多，深有体会，这是需要优化的

• 架构腐化

随着时间和版本的迭代，可能会偷懒打破这种三层依赖关系，导致问题蔓延，发生架构异味，失去三层架构的初衷