前端整洁架构,你了解多少?


前端整洁架构,你了解多少?

文章插图
本文来聊一聊前端整洁架构 。
首先,总体了解什么是"整洁架构",并熟悉领域、用例和应用层等概念 。然后,讨论它如何应用于前端,以及它是否值得使用 。然后,按照整洁架构的规则设计一个商店应用,并从头开始设计一个用例,看看它是否可用 。这个应用使用 React、TypeScript 编写,编写过程中会考虑可测试性,并对其进行改进 。
架构与设计
设计的基本目标是以一种能够重新组合的方式将事物分解开来...将事物分成可以组合的部分,这就是设计 。— Rich Hickey,《Design Composition and Performance》
正如上述引言中所说,系统设计是将系统分开以便以后重新组装 。最重要的是,能够轻松地重新组装,而不需要太多的工作 。
我同意这个观点 。但我认为架构的另一个目标是系统的可扩展性 。对程序的需求不断变化 。我们希望程序能够轻松更新和修改以满足新的需求,整洁架构可以帮助实现这个目标 。
整洁架构整洁架构是一种根据职责和功能部分与应用程序域的接近程度来分离它们的方法 。
所谓领域,是指用程序建模的现实世界的一部分 。这是反映现实世界变化的数据转换 。例如,如果我们更新了产品的名称,用新名称替换旧名称就是一个领域转换 。
整洁架构通常被分为三层,如下图所示:
前端整洁架构,你了解多少?

文章插图
层次图:领域层在中心,应用层在周围,适配器层在外侧
领域层整洁架构的中心是领域层 。它是描述应用主题区域的实体和数据,以及转换该数据的代码 。领域是区分不同应用的核心 。
我们可以将领域视为当我们从 React 迁移到 Angular,或者更改某些用例,那些不会改变的东西 。就商店而言,领域就是产品、订单、用户、购物车和更新数据的方法 。
领域实体的数据结构及其转换的本质是独立于外部世界的 。外部事件触发领域的转换,但并不决定转换将如何发生 。
将商品添加到购物车的功能并不关心商品的添加方式:用户自己通过“购买”按钮添加或使用促销码自动添加 。在这两种情况下,它都会接受该商品并返回包含添加商品的更新后的购物车 。
应用层在领域层的周围是应用层 。这一层描述了用例,即用户场景 。它们负责在某个事件发生后发生的事情 。
例如,“添加到购物车”场景就是一个用例 。它描述了单击按钮后应执行的操作 。它会告诉应用:
  • 发送请求 。
  • 执行这个领域转换 。
  • 使用响应数据重新绘制 UI 。
此外,在应用层中还有端口——应用程序希望与外界进行通信的规范 。通常,端口是一个接口,表示行为契约 。
端口充当我们的应用期望和现实之间的“缓冲区” 。输入端口告诉应用希望如何与外界通信 。输出端口说明应用将如何与外界进行通信以使其做好准备 。
适配器层最外层包含外部服务的适配器 。需要适配器将外部服务的不兼容 API 转换为与应用的可以兼容的 API 。
适配器是降低代码与第三方服务代码耦合度的好方法 。低耦合度可以减少在其他模块发生变化时需要修改一个模块的情况 。
适配器通常分为两类:
  • 驱动型适配器:向应用发送信号 。
  • 被驱动型适配器:接收来自应用的信号 。
用户通常与驱动型适配器进行交互 。例如,UI框架处理按钮点击的工作就是驱动型适配器的工作 。它与浏览器API(基本上是第三方服务)进行交互,并将事件转换为应用能够理解的信号 。
被驱动型适配器与基础设施进行交互 。在前端,大部分基础设施都是后端服务器,但有时也可能直接与其他服务进行交互,如搜索引擎 。
注意,离中心越远,代码功能越“面向服务”,离应用的领域知识越远 。当决定每个模块属于哪个层时,这将很重要 。
依赖规则三层架构有一个依赖规则:只有外层可以依赖内层 。 这意味着: