关于前端:前端的Clean-Architecture

在开始之前：

• 我的项目源码在这里
• 一个 demo 在这里

打算是什么

首先，咱们要大略的介绍一下什么是 clean architecture，而后相熟一下 domain，用例和分层的概念。而后咱们来讨论一下这些怎么用在前端，和是否有这个必要。

接下来，咱们用 clean architecture 的准则来设计一个饼干商店。并从头实现某个用例来看看可行性。

这个商店的界面局部会应用 React，这样咱们能够看看这个准则是否能够和 React 专用，尽管 React 不是必须的，其实什么 UI 框架、库都是能够的。

在代码里会有一部分 TypeScript，只是用来展现如何应用类型和接口来形容实体。咱们明天看到的代码都能够不必 TypeScript，除非无奈表白。

本文根本不会议论 OOP，所以这个文章应该不会触动某些人的神经。只会在文末提一次，然而和理论咱们的利用没什么太大关系。

而且本文也不会提及测试，因为这不是本文的重点。

机构和设计

设计就是把事物拆分。。。用一种之后能够拼接在一起的办法。。。把事物拆分成能够组合在一起的事物就是设计 -- Rich Hickey《设计、重组和性能》

零碎设计，如上援用，就是为了日后能够重组而进行的零碎宰割。很重要的一点就是日后的重组不会消耗太多资源。

我（作者）很批准，然而架构的另外一个指标也是不得不思考的，那就是可扩展性。对利用的需要是一直变更的。咱们须要咱们的程序能够疾速的更新或者批改以满足新的需要。Clean architecture 在这方面能够一显身手。

Clean Architecture

Clean architecture 是一种依据利用的域（domain）的相似性来宰割职责和功能块的办法。

域（domain）是由真实世界形象而来的程序模型。是真实世界数据转化在程序的映射。

Clean architecture 总是会用到一个三层架构，在这里性能被分层。原始的 clean architecture 则提供了一张如下的图：

图片来自这里。

域（domain）分层

在核心的是域（domain)层。这里是形容利用的主题区域的实体和数据，以及数据转换的代码。域（domain）是辨别不同程序的外围。

你能够把它了解为当咱们从 React 换到 Angular，或者扭转某些用例的时候不会变的那一部分。在饼干商店这个例子里就是产品、订单、用户、购物车和更新这些数据的办法。

数据结构和他们之间的转化与内部世界是互相隔离的。内部世界会触发域的转化然而并不会决定他们如何运行。

给购物车减少物品的办法并不关怀这个数据是如何加上去的：用户点击“购买”按钮或者应用了促销卡之类的。两种状况都会减少一个物品，并且返回一个更新之后的购物车对象。

应用层（Application Layer）

围在域（domain）里面的是应用层。这一层形容了用例（use cases），比方某些用户场景。他们形容了某些事件产生后会产生什么。

比方，“增加到购物车”这个场景是一个用例，它形容了再点击这个按钮之后会产生什么。就像是某种“指挥家”：

• 向 server 发送一个申请
• 执行域（domain)转换
• 依据返回的数据更新 UI

同时，在应用层还会有一些接口（port）– 它形容了内部世界如何和应用层沟通。一般来说一个接口就是一个 interface，一个行为契约。

接口（port)也能够被认为是一个事实世界和应用程序的“缓冲区”。输出 Port 通知咱们利用要如何承受内部的输出，同样输入 Port 通知咱们会如何告知内部间接利用的信息。

上面来看一些细节:

适配层

最外层蕴含了对外部的各种适配器。这些适配器要把里面不兼容的 API 转换成利用须要的样子。

这些适配器能够极大的升高咱们和内部第三方代码的耦合。升高耦合意味着只有很好的代码批改就能够适配其余模块的变动。

适配器个别分为：

• 驱动型 — 向咱们的利用发送音讯的
• 被动型 — 承受咱们的利用所发送的音讯

用户最长接触的是驱动型适配器。比方，解决 UI 层发送的点击事件就是一个驱动型适配器。它会依据浏览器 API 把一个事件转换为一个咱们的利用能够了解的信号。

驱动型适配器和咱们的基础设施相交互。在前端，最常见的基础设施就是后端。当然也会和其余的服务间接交互。

留神，离核心越远，也就是离利用的域（domain）越远，代码的性能就越是“面向服务”的。这在前面咱们要决定一个模块是哪一层的时候是十分重要的。

依赖规定

三层架构有一个以来规定：只有外层的能够依赖内层。也就是：

• 域（domain）必须独立
• 应用层能够依赖于域（domain)
• 最外层能够依赖于任何货色

某些时候这条铁律能够违反，不过尽量不要这么做。比方：有时在域的范畴内能够应用一些内部的“库”一样的代码，即便这个时候其实应该是没有依赖的。在探讨源码的时候咱们会看到这个例子。

依赖方向不受控的代码会变得非常复杂和难以保护。比方，不恪守依赖规定会：

• 循环依赖，A 模块依赖 B 模块，B 模块依赖 C 模块，而后 C 模块又依赖于 A 模块
• 低可测，即便测试一小块性能也不得不模仿整个零碎
• 高耦合，模块之间的调用极易出问题

Clean Architecture 的劣势

当初咱们来探讨下代码宰割能够给咱们带来怎么的益处。

宰割域（domain）

所有的利用的性能都是独立的，并且集中在一个中央 — 域。

域的性能是独立的也就是说它更容易测试。模块的依赖越少，测试的时候须要的基础设施就越少，mock 和桩模块也就越少。

一个绝对独立的域也很容易测试它是否满足需要。这让老手更容易了解利用是做什么的。另外，一个独立的域也让从需要到代码实现中呈现的谬误和不精确更容易排除。

独立的用例（Use Case)

利用的应用场景和用例都是独立形容的。它表明了咱们所须要的第三方服务。咱们让内部服务为咱们所用，而不是削足适履。这让咱们有更多的空间能够抉择适合的第三方服务。比方，一旦一个免费服务收取更高的佣金的时候咱们能够很快的换掉它。

用例的实现代码也是扁平的，已测试，有足够的扩展性。咱们会在前面的代码看到这一点。

可更换的第三方服务

适配器让内部服务变容易更换。只有咱们不更换接口，那么实现这个接口的是哪个第三方服务是无关紧要的。

这样能够建设一个批改流传的屏障：批改是某个人的批改，不会间接影响咱们。适配器也会在利用运行时缩小 bug 的流传。

Clean Architecture 的代价

架构首先是一个工具。和所有工具一样，clean architecture 带来益处的同时并不是没有代价的。

工夫

耗费最多的是工夫。设计和实现都须要耗费额定的工夫，因为咱们在开始的时候就晓得所有的需要和束缚。在设计的时候咱们就须要注意哪些地方会产生批改，并为此留下批改的空间。

有时会适度冗余

一般来说，经典的 clean architecture 实现会带来不便，有时甚至无害。如果是一个小我的项目的，齐全照本宣科的实现会贬低实现门槛，劝退老手。

为了满足资金或者交付日期，不得不做一些取舍。前面会用代码来阐明这些取舍都是什么。

上手更难

齐全的依照 clean architecture 的实现会让新手上路更难。任何的工具都须要先理解这个工具是如何运行的。

如果你在我的项目初期就适度设计，前面就会减少新同学的上手难度。记住这一点，尽量放弃代码的简略。

减少代码量

对于前端来说，实际 clean architecture 会减少打包后的体积。咱们给浏览器的代码越多，它就不得不花更多的下载和解析的工夫。

代码量的问题须要从一开始就把控好，能少的中央尽量少：

• 让用例更加简略
• 间接和适配器交互，绕开用例
• 应用代码宰割

如何缩小代价

能够适度损失代码的纯洁性来缩小下面说到的损失。我（作者）不是一个激进的人，如果能够取得更大的益处要毁坏一些代码的纯洁性，那也是能够的。

所以，不用方方面面都恪守 clean architecture 的条条框框。然而最低限度的两条须要认真对待：

抽离域（Domain)

对域的抽离能够帮忙咱们了解咱们正在设计的是什么，它是如何工作的。抽离进去的域也会让其余的开发同学更容易了解利用是如何运作的。

即便抛开其余几层不谈，拆散的域也更加容易重构。因为它的代码没有扩散在利用的各个中央。其余层能够更具须要增加。

恪守依赖规定

第二个不能摈弃的规定是依赖规定，或者说是他们的方向。内部的服务须要适配到外部的服务，而不是反方向。

如果你感觉间接调用一个搜寻 API 也没什么问题，那么这就是问题所在了。最好在问题没有扩散之前写一个适配器。

设计利用

之前都是务实，当初咱们来写一些代码。咱们来设计一下这个饼干店的架构吧。

这个饼干店要售卖不同品种、不同配方的饼干。用户能够抉择饼干并下单，之后应用第三方的领取服务来下单。

还首页有能够买的饼干展现。咱们只能在认证之后才能够购买饼干。登录按钮会把咱们带到登录页。

（界面有点丑，因为没有设计师帮忙）

胜利登录之后，咱们就能够往购物车里加饼干了。

当购物车里有饼干之后就能够下单了。领取之后，生成订单并清空购物车。

咱们会实现下面说的性能，其余的用例能够在源码中找到。

首先咱们定义狭义上的实体、用例和性能。之后把他们划分到不同的层里。

设计域（domain)

程序开发中最重要的是就是域的解决。这是实体和数据转换的所在。我倡议从域开始在代码中能够准确的展示域常识（domain knowledge）。

店铺的域包含：

• 不同实体的类型：User、Cookie、Cart 和 Order
• 如果你是用 OOP 实现的，那么也包含生成实体的工厂和类
• 以及这些数据转换的办法

域（domain）里的数据转换方法应该是只依赖于域的规定，而不是其余。比方办法应该是：

• 计算总价的办法
• 检测用户口味的办法
• 检测一个物品是否在购物车的办法

设计应用层

应用层蕴含用例，一个用例蕴含一个执行人、一个动作和一个后果。

在饼干店这个例子里:

• 一个产品购买场景
• 领取，调用第三方领取零碎
• 与产品和订单的交互，更新和搜寻
• 依据角色不同拜访不同页面

用例个别都是用主题畛域形容，比方购买流程有以下步骤:

• 获取购物车里的物品，并新建一个订单
• 领取订单
• 如果领取失败，告诉用户
• 领取胜利，清空购物车，显示订单

这个用例最初会变成实现这个性能的代码。

同时，在应用层还有各种和外界沟通是须要的接口。

设计应用层

在适配器层，咱们申明连贯内部服务的适配器。适配器让不兼容的内部服务和咱们的零碎兼容。

在前端，适配器个别是 UI 框架和对后端的 API 申请模块。在本例中咱们会用到：

• UI 框架
• API 申请模块
• 对本地存储的适配器
• API 返回到应用层的适配器

应用 MVC 做类比

有时咱们数据是属于哪一层的。一个小的（兴许不残缺)的 MVC 的类比能够用的上：

• Model 个别都是域实体
• 控制器（Controller）个别是与转换或者应用层
• 试图是驱动适配器

这些概念在细节上不尽相同然而外行十分类似，这个类比能够用在定义域和利用代码。

深刻细节: 域

一旦咱们决定了咱们所须要的实体，咱们就能够定义相干的行为了。

我当初就会给你看我的项目的代码细节。为了容易了解我把代码分为不同的目录：

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/

域都定义在 domain 目录下，应用层在 application 目录下，适配器都在 service 目录下。咱们会探讨目录构造是否会有其余的可行计划。

新建域实体

在域内蕴含了四个实体:

• product
• user
• order
• shopping cart

这些实体最重要的是 user。在会话中，咱们会把用户实体存储起来。同时咱们会给 user 减少类型。

用户实体蕴含 ID，name，mail 以及 preferences 和allergies数组。

// domain/user.ts

export type UserName = string;
export type User = {
  id: UniqueId;
  name: UserName;
  email: Email;
  preferences: Ingredient[];
  allergies: Ingredient[];};

用户能够把饼干放进购物车，咱们也给购物车和饼干加上类型。

// domain/product.ts

export type ProductTitle = string;
export type Product = {
  id: UniqueId;
  title: ProductTitle;
  price: PriceCents;
  toppings: Ingredient[];};

// domain/cart.ts

import {Product} from "./product";

export type Cart = {products: Product[];
};

在领取胜利之后，会新建一个订单。咱们也给订单实体加上类型:

// domain/order.ts

export type OrderStatus = "new" | "delivery" | "completed";

export type Order = {
  user: UniqueId;
  cart: Cart;
  created: DateTimeString;
  status: OrderStatus;
  total: PriceCents;
};

了解实体之间的关系

给实体增加类型之后，能够查看实体关系图和理论状况是否合乎

咱们能够查看的点：

• 次要的参与者是否是一个 user
• 在订单里是否有足够的信息
• 是否有些实体须要扩大
• 在将来是否有足够的可扩展性

同时，在这个阶段，类型能够帮忙辨认实体之间的信息和调用的谬误。

创立数据转换

用例的行为会产生在不同的实体之间。咱们能够给购物车增加物品、清空购物车、更新物品和用户名称，等。咱们会别离新建办法来实现上述性能。

比方，为了判断某个用户对不同的口味是喜爱还是讨厌。咱们能够定义 hasAllergy 和hasPreference。

// domain/user.ts

export function hasAllergy(user: User, ingredient: Ingredient): boolean {return user.allergies.includes(ingredient);
}

export function hasPreference(user: User, ingredient: Ingredient): boolean {return user.preferences.includes(ingredient);
}

办法 addProduct 和contains用来给购物车增加物品和查看一个物品是否在购物车里

// domain/cart.ts

export function addProduct(cart: Cart, product: Product): Cart {return { ...cart, products: [...cart.products, product] };
}

export function contains(cart: Cart, product: Product): boolean {return cart.products.some(({ id}) => id === product.id);
}

咱们也须要计算总价，所有须要 totalPrice 办法。如果需要的话咱们还能够让这个办法满足不同的场景，比方促销码，淡季打折，等：

// domain/product.ts

export function totalPrice(products: Product[]): PriceCents {return products.reduce((total, { price}) => total + price, 0);
}

为了让用户创立订单，咱们还须要办法createOrder。它会返回一个新的订单，并和对应用户以及他的购物车关联。

// domain/order.ts

export function createOrder(user: User, cart: Cart): Order {
  return {
    user: user.id,
    cart,
    created: new Date().toISOString(),
    status: "new",
    total: totalPrice(products),
  };
}

在设计阶段是蕴含内部束缚的。这让咱们的数据转换尽量贴近主题域。而且转换越贴近理论，就越容易查看代码是否牢靠。

细节设计：共享的内核

你兴许曾经留神到咱们在形容域的时候的一些类型，比方：Email，UniqueId或者DateTimeString。这些都是类型别名:

// shared-kernel.d.ts

type Email = string;
type UniqueId = string;
type DateTimeString = string;
type PriceCents = number;

我个别应用类型别名防止原始类型偏执。

我用 DateTimeString 而不是 string 来更加清晰的表明这个字符串是用来做什么的。这些类型越贴近理论，当前排除就越容易。

这些类型都在 shared-kernel.d.ts 文件里。Shared Kernel 是一些代码和数据，他们不会减少模块之间的耦合度。更多对于这个话题的内容，你能够在 DDD, Hexagonal, Onion, Clean, CQRS, …How I put it all together 找到。

在实践中，共享内核能够这样解释。咱们用了 typescript，用了它的规范类型库，然而咱们不认为这是依赖。这是因为应用了它的模块相互之间一样维持了“常识起码 ” 准则，一样是低耦合的。

并不是所有的代码都能够作为共享内核。最次要的准则是这样的代码必须和零碎处处兼容。如果利用一部分是用 typescript 开发的，一部分是其余语言。那么，共享外围只能够蕴含两种语言都能够工作的局部。比方，实体阐明用 JSON 是没问题的，然而用 typescript 就不行。

在咱们的例子里，整个利用都是用 typescript 写的，所以类型别名齐全能够当做共享外围的一部分。这样的全局可用的类型并不会减少模块之间的耦合，并且能够在利用的任何中央应用。

深刻细节: 应用层

当初咱们曾经实现了域这一部分的设计，咱们以思考应用层了。这一层蕴含 i 了用例。

在代码里会包含每个场景的细节。一个用例形容了增加一个物品到购物车或者购买的时候包含的一系列步骤。

用例蕴含了利用和内部服务的交互。与内部服务的交互都是副作用。咱们晓得调用或者调试没有副作用的办法更简略一些。咱们的域的办法都是纯办法。

为了汇合外部的纯办法和内部的非纯世界，咱们能够把应用层当做非纯的上下文。

非纯上下文域纯数据转换

一个非纯上下文和纯数据转换是这样一种代码组合:

• 首先执行副作用获取数据
• 之后对数据执行纯数据转化
• 最初执行一个副作用，存储或者传递数据

在”往购物车增加物品“这个用例，看起来是这样的:

• 首先，能够从数据库里获取购物车的状态
• 而后调用办法把能够存进购物车的物品更新到购物车里
• 之后把更新的购物车存到数据库里

整个过程就是一个三明治：副作用、纯办法、副作用。

非纯上下文有时叫做性能外围，因为它是异步的，和第三方服务有很多交互，这样的称说也很有代表性的。其余的场景和代码都在 github 上。

让咱们来想一想，通过整个用例咱们要达到什么。用户的购物车里有一些饼干，当用户点击购买按钮的时候：

• 咱们要新建一个订单
• 应用第三方领取零碎领取
• 领取失败，告诉用户
• 领取胜利，把订单保留到后端
• 在本地存储保留订单数据，并在页面上显示

在 API 或者办法的签名上，咱们会把用户和购物车都作为参数，而后让这个办法把其余的都实现了。

type OrderProducts = (user: User, cart: Cart) => Promise<void>;

最好的状况，当然不是别离接管两个参数，而是把他们封装一下。然而，目前咱们先放弃现状。

编写应用层的接口

咱们再来看看用例的细节：新建订单自身是域的办法。其余的都是咱们用到的内部办法。

谨记一点，内部办法要适配咱们的须要而不是反过来。所以，在应用层，咱们不仅要形容用例自身，也要定义调用内部服务的接口。

咱们来看看须要的服务：

• 领取服务
• 告诉用户事件、谬误的服务
• 把数据保留在本地存储的服务

留神咱们探讨的是这些服务的接口，不是他们的实现。在这一阶段，形容必要的步骤十分重要。因为，在应用层的某些场景里，这些都是必要的。

如何实现当初不是重点。这样咱们能够在最初再思考调用哪些内部服务，这样代码能力尽量保障低耦合。

同时须要留神，咱们会依据性能点宰割接口。领取相干的都在一个模块下，存储相干的在另外一个。这样能够确保不同的第三方服务不会混在一起。

领取零碎接口

饼干点是一个简略的利用，所以领取零碎也很简略。它会蕴含一个 tryPay 的办法，它会接管须要领取的金额作为参数，而后返回一个表明领取后果值。

// application/ports.ts

export interface PaymentService {tryPay(amount: PriceCents): Promise<boolean>;
}

咱们不会在这里处理错误返回，解决返回的谬误是一个大话题，能够再写一篇博文了。

一般来说，领取的解决是在后端。然而这是一个简略的利用，咱们在客户端就都解决了。咱们也会简略的调用 API，而不是间接调用领取零碎。这个改变只会影响以后的用例，其余的代码都没有动到。

告诉服务接口

如果出了什么问题，须要告诉用户。

能够应用不同的办法告诉用户。咱们能够用 UI，能够发邮件，或者用户的手机触动（千万别这么干）。

基本上，告诉服务最好也形象进去，这样咱们当初就不必思考实现的问题了。

咱们来给用户发送一个告诉音讯：

// application/ports.ts

export interface NotificationService {notify(message: string): void;
}

本地存储接口

咱们会把新建的订单存储在本地。

这个存储能够是多种多样的：Redux、MobX，任何能够存储的都能够。存储空间能够是为每个不同的性能点宰割进去的，也能够是全副都放在一起的。当初这个不重要，因为这些都是实现的细节。

我喜爱把存储接口为每个实体做宰割。一个独自的接口存储用户数据，一个存储购物车，一个存储订单：

// application/ports.ts

export interface OrdersStorageService {orders: Order[];
  updateOrders(orders: Order[]): void;
}

这个例子里只有订单存储的接口，其余的在 GitHub。

用例办法

咱们来看看能不能用域办法和刚刚建的接口来实现一个用例。脚本将蕴含如下步骤：

• 验证数据
• 新建订单
• 领取订单
• 告诉问题
• 保留后果

首先，咱们定义进去咱们要调用的桩模块。TypeScript 会提醒咱们没有给出接口的实现，先不要管他。

// application/orderProducts.ts

const payment: PaymentService = {};
const notifier: NotificationService = {};
const orderStorage: OrdersStorageService = {};

咱们当初把这些桩模块当作真是的代码应用。咱们能够拜访这些字段和办法。这样在把用例转换为代码的时候十分有用。

当初新建一个办法：orderProducts。在这里，首先要做的就是新建一个订单：

// application/orderProducts.ts
//...

async function orderProducts(user: User, cart: Cart) {const order = createOrder(user, cart);
}

这里，咱们把接口当作是行为的约定。也就是说当前桩模块是要实在执行咱们心愿的动作的。

// application/orderProducts.ts
//...

async function orderProducts(user: User, cart: Cart) {const order = createOrder(user, cart);

  // Try to pay for the order;
  // Notify the user if something is wrong:
  const paid = await payment.tryPay(order.total);
  if (!paid) return notifier.notify("Oops! 🤷");

  // Save the result and clear the cart:
  const {orders} = orderStorage;
  orderStorage.updateOrders([...orders, order]);
  cartStorage.emptyCart();}

留神用例并不会间接调用第三方服务。而是依赖于接口是如何定义的，只有接口的定义没改，那个模块首先它，如何实现它当初并不重要。这样能力让模块可替换。

适配层实现细节

咱们曾经把用例 ” 翻译 ” 成了 TypeScript。咱们来检查一下代码是否合乎咱们的须要。

通常不合乎。所以咱们要通过适配器调用第三方服务。

增加 UI 和用例

第一个适配器是 UI 框架。它把浏览器的原生 API 和利用连贯到了一起。在新建订单的例子里，它就是领取按钮和对应事件的解决办法。

// ui/components/Buy.tsx

export function Buy() {
  // Get access to the use case in the component:
  const {orderProducts} = useOrderProducts();

  async function handleSubmit(e: React.FormEvent) {setLoading(true);
    e.preventDefault();

    // Call the use case function:
    await orderProducts(user!, cart);
    setLoading(false);
  }

  return (
    <section>
      <h2>Checkout</h2>
      <form onSubmit={handleSubmit}>{/* ... */}</form>
    </section>
  );
}

咱们通过一个 hook 来实现用例。咱们会把所有的服务都放在外面，最初返回用例的办法：

// application/orderProducts.ts

export function useOrderProducts() {const notifier = useNotifier();
  const payment = usePayment();
  const orderStorage = useOrdersStorage();

  async function orderProducts(user: User, cookies: Cookie[]) {// …}

  return {orderProducts};
}

咱们应用 hook 来当作一个依赖注入。首先咱们应用 hooksuseNotifier，usePayment，useOrdersStorage来获取服务实例，而后咱们用 useOrderProducts 闭包，让他们能够在 orderProducts 能够应用。

有一点很重要，用例办法和其余的代码是拆散的，这样对测试更加敌对。

领取服务的实现

这个用例用了 PaymentService 接口，咱们来实现这个接口。

领取的具体实现还是用了假的 API 来模仿。咱们当初还是没有必要重写全副的服务，咱们能够之后再实现。最重要的是实现指定的行为：

// services/paymentAdapter.ts

import {fakeApi} from "./api";
import {PaymentService} from "../application/ports";

export function usePayment(): PaymentService {
  return {tryPay(amount: PriceCents) {return fakeApi(true);
    },
  };
}

fakeApi办法是一个定时办法，将在 450ms 之后执行。这样来模仿一个从后端返回的申请。它会把咱们传入的参数返回。

// services/api.ts

export function fakeApi<TResponse>(response: TResponse): Promise<TResponse> {return new Promise((res) => setTimeout(() => res(response), 450));
}

告诉服务的实现

告诉在本例中将是一个简略的alert。只有代码是解耦的，当前从新实现不会是一个问题。

// services/notificationAdapter.ts

import {NotificationService} from "../application/ports";

export function useNotifier(): NotificationService {
  return {notify: (message: string) => window.alert(message),
  };
}

本地存储的实现

本例中本地存储就是 React.Context 或者 hooks。咱们新建一个 context，而后把值传给 provider，再 export 进来让其余的模块能够通过 hooks 应用。

// store.tsx

const StoreContext = React.createContext<any>({});
export const useStore = () => useContext(StoreContext);

export const Provider: React.FC = ({children}) => {
  // ...Other entities...
  const [orders, setOrders] = useState([]);

  const value = {
    // ...
    orders,
    updateOrders: setOrders,
  };

  return (<StoreContext.Provider value={value}>{children}</StoreContext.Provider>
  );
};

咱们会给每一个性能点都写一个 hook。这样咱们不会毁坏服务接口和存储，至多在接口的角度来说他们是拆散的。

// services/storageAdapter.ts

export function useOrdersStorage(): OrdersStorageService {return useStore();
}

同时这样的办法让咱们能够给每个存储额定的优化，咱们能够新建 selector、缓存等。

验证数据流图

当初咱们来验证一下用户能够如何与利用交互。

用户通过 UI 层与利用交互，然而 UI 层也是通过特定的接口与利用交互。所以，想换 UI 就能够换。

用例是在应用层解决的，这让咱们很分明须要什么内部服务。所有的主数据和逻辑都在域层。

所有的内部服务都放在基础架构，并且恪守咱们的标准。如果咱们须要更换发送音讯服务，只须要批改内部服务的适配器。

这样的模式让代码更加容易随着需要的变更而替换、扩大、测试。

什么能够更好

总体来说，这些曾经足够让你理解什么是 clean architecture 了。然而我得指出那些中央为了让 demo 简略而做了简化。

这一节不是必须的，然而会给出一个扩大，让大家理解一个没有缩水的 clean architecture 是什么样子的。

我会着重阐明还有哪些事件能够做：

应用对象而不是数字来示意价格

你应该留神到了，我应用数字示意了价格。这不是一个好办法：

// shared-kernel.d.ts

type PriceCents = number;

一个数字只表明了数量而没有表明货币品种，一个没有货币的价格是没有意义的。现实情况下是价格有两个字段示意：值和货币。

type Currency = "RUB" | "USD" | "EUR" | "SEK";
type AmountCents = number;

type Price = {
  value: AmountCents;
  currency: Currency;
};

这样就能够省去大量的存储和解决货币的精力了。在实例中没有这么做是为了让这个例子尽量简略。在实在的状况里，价格的构造会更加靠近下面的写法。

另外，价格的单位也很重要。比方美元的最小单位是分。这样显示价格就能够防止计算小数点前面的数字，也就能够防止浮点数计算了。

应用性能点宰割代码，而不是依照层

代码建在那个目录下是依照性能点宰割的，而不是依照层宰割。一个性能点就是上面饼图的一部分。

下图的这个构造更加清晰。你能够别离部署不同的性能点，这在开发中很有用。

图片来自这里

同时强烈建议读一下上图所在的文章。

同时倡议浏览性能拆分，概念上和组件代码拆分很类似，然而更容易了解。

留神跨组件代码

在咱们探讨零碎拆分的时候，就不得不说道跨组件代码应用的问题。咱们再来看看新建订单的代码：

import {Product, totalPrice} from "./product";

export function createOrder(user: User, cart: Cart): Order {
  return {
    user: user.id,
    cart,
    created: new Date().toISOString(),
    status: "new",
    total: totalPrice(products),
  };
}

这个办法是用了从别的代码 Product 模块引入的totalPrice。这样应用自身没有什么问题，然而如果咱们要把代码划分到独立的性能的时候，咱们不能间接拜访其余性能的代码。

你也能够在这里和这里这找到办法。

应用类型标签，而不是类型别名

在外围代码里我用了类型别名。这样很容易操作，然而毛病也很显著，TypeScript 没方法更多的施展它的强项。

这仿佛不是个问题，即应用了 string 而不是 DateTimeString 类型也不会怎么样，代码还是能够编译胜利。

问题是束缚松的类型是能够编译的（另一个说法是前置条件减弱）。首先这样会让代码变得软弱，因为这样你能够用任意的字符串，显然会导致谬误。

有个方法能够让 TypeScript 了解，咱们想要一个特定的类型 — 应用类型标签。这些标签会让类型更加平安，然而也减少了代码复杂度。

留神域里的可能的依赖

下一个要留神的在新建订单的时候会新建一个日期：

import {Product, totalPrice} from "./product";

export function createOrder(user: User, cart: Cart): Order {
  return {
    user: user.id,
    cart,

    // Вот эта строка:
    created: new Date().toISOString(),

    status: "new",
    total: totalPrice(products),
  };
}

能够预感 new Date().toISOString() 会在我的项目里反复很屡次，咱们最好把它放进一个 helper 里。

// lib/datetime.ts

export function currentDatetime(): DateTimeString {return new Date().toISOString();}

而后这么用：

// domain/order.ts

import {currentDatetime} from "../lib/datetime";
import {Product, totalPrice} from "./product";

export function createOrder(user: User, cart: Cart): Order {
  return {
    user: user.id,
    cart,
    created: currentDatetime(),
    status: "new",
    total: totalPrice(products),
  };
}

然而咱们立即想到一件事，咱们不能在域里依赖任何货色。所以怎么办呢？所以 createOrder 最好是所有数据都从里面传进来。日期能够作为最初一个参数。

// domain/order.ts

export function createOrder(
  user: User,
  cart: Cart,
  created: DateTimeString
): Order {
  return {
    user: user.id,
    products,
    created,
    status: "new",
    total: totalPrice(products),
  };
}

这样咱们也不会毁坏依赖规定，万一新建日期须要依赖第三方库呢。如果咱们用域以外的办法新建日期，基本上就是在用例新建日期而后作为参数传递。

function someUserCase() {
  // Use the `dateTimeSource` adapter,
  // to get the current date in the desired format:
  const createdOn = dateTimeSource.currentDatetime();

  // Pass already created date to the domain function:
  createOrder(user, cart, createdOn);
}

这让域更加独立，更容易测试。

在这个例子里因为两点起因我不会次要关注这一点：偏离主线。而且只是依赖本人的 helper 也没什么问题。尤其这个 helper 只是用了语言个性。这样的 helper 甚至能够作为共享的外围（kernel），还能缩小反复的代码。

留神购物车和订单的关系

在这个例子里，订单蕴含了购物车，因为购物车只是代表了一列产品：

export type Cart = {products: Product[];
};

export type Order = {
  user: UniqueId;
  cart: Cart;
  created: DateTimeString;
  status: OrderStatus;
  total: PriceCents;
};

如果购物车有其余的和订单没有关联的属性，恐怕会出问题。比方最好应用数据映射或者两头 DTO。

作为一个选项，咱们能够用 ProductList 实体。

type ProductList = Product[];

type Cart = {products: ProductList;};

type Order = {
  user: UniqueId;
  products: ProductList;
  created: DateTimeString;
  status: OrderStatus;
  total: PriceCents;
};

让用例更容易测试

用例有很多能够探讨的。当初 orderProducts 办法脱离开 React 之后很难测试，这就很不好了。现实状态下，它应该能够在最小代价下测试。

问题是当初用了 hook 实现了用例。

// application/orderProducts.ts

export function useOrderProducts() {const notifier = useNotifier();
  const payment = usePayment();
  const orderStorage = useOrdersStorage();
  const cartStorage = useCartStorage();

  async function orderProducts(user: User, cart: Cart) {const order = createOrder(user, cart);

    const paid = await payment.tryPay(order.total);
    if (!paid) return notifier.notify("Oops! 🤷");

    const {orders} = orderStorage;
    orderStorage.updateOrders([...orders, order]);
    cartStorage.emptyCart();}

  return {orderProducts};
}

在经典的实现中，用例办法能够放在 hook 的里面，其余的服务能够做为参数或者应用 DI 传入用例：

type Dependencies = {
  notifier?: NotificationService;
  payment?: PaymentService;
  orderStorage?: OrderStorageService;
};

async function orderProducts(
  user: User,
  cart: Cart,
  dependencies: Dependencies = defaultDependencies
) {const { notifier, payment, orderStorage} = dependencies;

  // ...
}

hook 能够作为适配器。

function useOrderProducts() {const notifier = useNotifier();
  const payment = usePayment();
  const orderStorage = useOrdersStorage();

  return (user: User, cart: Cart) =>
    orderProducts(user, cart, {
      notifier,
      payment,
      orderStorage,
    });
}

这之后 hook 的代码就能够当做一个适配器，只有用例还留在应用层。orderProdeucts办法很容易就能够被测试了。

配置主动依赖注入

在应用层咱们都是手动注入依赖的：

export function useOrderProducts() {
  // Here we use hooks to get the instances of each service,
  // which will be used inside the orderProducts use case:
  const notifier = useNotifier();
  const payment = usePayment();
  const orderStorage = useOrdersStorage();
  const cartStorage = useCartStorage();

  async function orderProducts(user: User, cart: Cart) {// ...Inside the use case we use those services.}

  return {orderProducts};
}

一般来说，这一条能够应用依赖注入实现。咱们曾经通过最初一个参数体验了一下最简略的依赖注入。然而还能够更进一步，配置自动化的依赖注入。

在某些利用里，依赖注入没什么用途。只会让开发者进入适度设计的泥潭。在用了 React 和 hooks 的状况下，他们能够当作返回某个接口实现的容器。是的，这样是手动实现，然而这样不会减少入门的门槛，也让新退出的开发者更容易了解代码。

哪些在理论开发中更简单

本文应用的代码专门提炼简化过了。事实上理论的开发要简单很多。所以我也是想讨论一下在理论应用 clean architecture 的时候有哪些问题会变得辣手。

分支业务逻辑

最重要的问题是咱们对主题域所知不多。假如店铺里有一个产品，一个打折的产品，一个登记的产品。咱们怎么能精确的形容这些实体呢？

须要一个能够被扩大的实体基类么？这个实体应该如何被扩大呢？要不要额定的字段？这些实体须要放弃互斥关系么？用例要如何解决更加简单的实体呢？

业务有太多的问题，有太多的答案。因为开发者和相干人都不晓得零碎运行的每个细节。如果只有假如，你会发现你曾经掉入剖析有力的陷阱。

每种状况都有特定的解决办法，我只能举荐几种概况的办法。

不要应用继承，即便它有时候被叫做 ” 扩大 ”。即便是看起来像接口，其实是继承。

复制粘贴的代码服用并非齐全不能够。建两个一样的实体，而后察看他们。有时候他们的行为会很有达的不同，有时候也只有一两个字段的区别。合并两个十分相近的实体比写一大堆的查看、校验好很多。

如果你肯定要扩大什么的话。。

记住 协变、逆变和不变，这样你就不会遇到工作量忽然减少的事件了。

应用相似于 BEM概念来抉择不同的实体和扩大。应用 BEM 的上下文来思考，让我受害很大。

相互依赖的用例

第二个问题是用例相干的。当一个用例须要另外的一个用例来登程的时候会引发的问题。

我惟一晓得，也是对我帮忙很大的一个办法就是把用例切分成更小的，更加原子的用例。这样他们更加容易组合在一起。

一般来说，呈现这个问题是另外一个大问题的后果。这就是实体组合。

曾经有很多人写过这个专题的文章了。比方这里有一整章对于这个话题的方法论。然而这里咱们就不深刻了，这个话题足够写一篇长文的。

结尾

在本文里，咱们介绍了前段的 clean architecture。

这不是一个黄金准则，更是一个在很多的我的项目、图标和语言上积攒的教训。我发现一个十分不便的办法能够帮忙你解耦你的代码。让层、模块和服务尽量独立。不仅在公布、部署上也变得独立，更是让你从一个我的项目到另一个我的项目到时候也更加容易。

咱们没有多讲 OOP，因为 OOP 和 clean architecture 是正交到。是的，架构探讨的是实体的组合，它不会强制开发者用类或者是办法作为单位。

至于 OOP，我写了一篇如何在 clean architecture 中应用 OOP。