架构方面学习笔记(3)-前端架构设计

LynnWonderLu

已于 2024-02-21 20:04:01 修改

阅读量2k

点赞数

分类专栏： webFE 文章标签：前端架构

于 2022-02-08 16:19:13 首次发布

本文链接：https://blog.csdn.net/lynnwonder6/article/details/122825042

版权

webFE 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

2022.02.08 今天读了一篇关于前端整洁架构的设计，因此对其中的内容进行了一些整理以及我自己的思考，后续阅读《领域驱动设计》后可以加入更多的内容。

References:

前端领域的 “干净架构”

架构方面学习笔记(3)–前端架构设计

文章目录

架构方面学习笔记(3)--前端架构设计

整洁架构

以一个🌰来介绍整洁架构：

商店会出售不同种类的饼干，用户可以自己选择要购买的饼干，并通过三方支付服务进行付款。

用户可以在首页看到所有饼干，但是只有登录后才能购买，点击登录按钮可以跳转到登录页。

把饼干加进购物车后，用户就可以付款了。付款后，购物车会清空，并产生一个新的订单。

在这里插入图片描述
上图明确出了整洁架构的三个部分，但它还是有一些抽象，在实际开发和设计中我们如何遵循这个架构进行设计呢？

明确实体，比如例子中的：商品、用户、购物车、订单。明确数据转换函数（必须仅依赖本层的各种实体和规则）如计算总价的方法
应用层：
- 列 use case：①找出参与者②找出动作③明确结果
- 写数据转换或者说描述 use case：side effect(从适配层与服务端的交互中拿数据) --> pure function(纯函数处理数据)–> side effect(存储处理结果)
- 列 Interfaces
适配层：
- 用户界面
- API 请求
- 存储或状态管理

最后：整洁架构让每个 use case 独立起来，同时适配层让第三方服务随时可替换，这会让整个架构扩展性极强，但不可避免的会带来一些如代码量的增大这种劣势。

我个人看法是整洁架构最关键的一点是希望逻辑和 UI、第三方服务能够分离，而如今的 react vue 都提倡使用 hooks，核心也正是如此。在现实开发中实现理想状态下的整洁架构当然是具有一定的难度和不可预测性，比如你真的可以做到逻辑和状态管理的真正分离吗，你的项目可以随意从 react 和 vue 中切换吗，诸如此类的问题。但梳理整洁架构的过程仍然给了我们不少启发：

通过列实体、列 use case 对于我们设计 store 结构具有很大的帮助
将逻辑从状态管理、第三方服务中剥离出来，尽量做到各司其职和不依赖框架的测试

// 整洁架构下的商品购买代码树
src/
|_domain/
  |_user.ts
  |_product.ts
  |_order.ts
  |_cart.ts
|_application/
  |_addToCart.ts
  |_authenticate.ts
  |_orderProducts.ts
  |_ports.ts
|_services/
  |_authAdapter.ts
  |_notificationAdapter.ts
  |_paymentAdapter.ts
  |_storageAdapter.ts
  |_api.ts
  |_store.tsx
|_lib/
|_ui/

DDD(Design Driven Design) 领域驱动设计

Reference:

领域驱动设计在互联网业务开发中的实践

《领域驱动设计》

特点：从开发到测试整个团队使用同一的架构语言；业务与架构强关联，从而建立针对业务变化的高响应力架构

几个名词解释：

DDD 中有较多的术语，这里仅写了几个，更多的可以参考领域驱动设计-什么是领域驱动设计和怎么使用它

领域：一个系统要解决的实际问题的集合，或者说业务本身
通用语言：所谓通用语言讲的并不是开发和测试都用一种开发语言，比如 golang，JavaScript 等，而是与领域模型相关的结构化语言保证整个团队对整个系统的理解一致，比如一个商城系统中的订单收货地址和个人信息收货地址应该明确区分，而不是混为一谈「收货地址」