简介：理论我的项目中积淀的数据流最佳实际。

数据流是前端始终以来都存在的一个问题，咱们我的项目积淀了一套最佳实际，如有问题，欢送探讨

在旧的 Done 我的项目中，代码复杂度高，曾经到了“牵一发而动全身”，技术债极高的状况。因为旧代码“盘根错节”，导致 实现一个简略的性能，都须要比失常工夫多 2～3 倍的工作估时。就像上面这张图的状况一样。

咱们仔细分析下现有的业务，会得出上面的业务个性：

1. 强畛域（比方：我的项目 / 文件 / 团队 / 用户畛域，在很多组件都会同时调用某个畛域下的办法，静音 / 点赞 / 转移我的项目……）
2. 单页面多且简单，组件过多，多层嵌套组件间通信多。
3. 业务曾经实现了从 0～1，目前正处于从 1～n 的阶段，在这个阶段，会大量基于用户倡议而做出产品交互的调整以打磨精品。需要数量增长，前端变动大，前端人力瓶颈大。

基于下面的业务个性，咱们再剖析目前我的项目中的问题：

• 模板代码过多，影响开发效率和可维护性
• 数据流螺旋呈网状调用（强耦合），代码复杂度急剧回升，牵一发而动全身
• 数据全局化
• 原始数据与展现数据转换
• UI 与 数据逻辑耦合，复用低

依据下面的特点和问题，咱们有以下的诉求：

1. 简略高效回绝模版代码
2. 升高代码复杂度（升高联动影响）
3. 晋升复用性极大水平的复用 UI / 逻辑层复用 数据转换

基于下面的问题和剖析，上面将一步步推导新的架构图 & 技术选型。

问题剖析

一、UI 与 数据逻辑耦合复用度低 & 原始数据与展现数据转换

原先的整体架构如下：Store 与 视图层混合在一起，一起解决用户行为和业务逻辑，耦合度高，复用率低。

架构演进：

改良点：独立的 Store 层，封装应用程序与业务逻辑相干的数据以及对数据的解决办法，在此处独立写逻辑，反对多处组件复用一个逻辑，与视图层独立，一个逻辑能够复用于多个组件。

家喻户晓，分层是为理解耦。假如 Store 层产生了扭转，那么在视图层不须要变动的，只须要批改 Store 层即可，这样改变的中央就少了，也晋升了开发效率 & 可维护性。

然而，咱们还遇到一些场景，当后端接口产生字段变动，要改变的中央切实太多太多。同一个接口，在不同中央展现，因为多人保护，他会通过屡次数据转换，最终映射到前端界面。因而，咱们再多一个 API 防腐层，专门解决前端界面和后盾界面的数据转换，这样，一旦数据结构发生变化，咱们也只须要在 API 层批改即可，毋庸关注到多个界面组件中。

改良点：独立 API 层，连接后端服务与前端服务，若后盾接口发生变化，可在此处进行对立批改，无需多处代码进行批改，不便在该层进行数据测验，预防后盾返回谬误的字段等等。

通过下面这样的分层，下面 2 个问题就迎刃而解了。

二、数据流网状调用

咱们对 Store 和 视图进行了分层，然而随着我的项目的迭代，又呈现了上面这种状况，数据流呈网状调用。

举一个例子：对我的项目设置静音

在旧的代码中，工作站会调用到团队中的数据，也会批改到团队中的数据，甚至接口回调后，他还会对各个中央波及到静音界面的相干数据都进行批改。

这会带来一个问题，因为是全局共用的 Redux，咱们在 A 中央调用这个办法，这里会更新 B 界面（B 中央并没有呈现在用户的界面上），也就是说，批改 A 中央的 action，还须要同时关注 B,C,D…… 这些中央（实际上，咱们并不需要关注其余的中央）

咱们晓得分层能够解耦，对升高复杂度十分无效。那咱们是否也能够对 Store 也进行分层，且束缚他们之间相互调用？

架构演进：

重构后，同层级的 store 不能相互调用，若须要调用，则阐明这个 store 要晋升到上一层级（下文有具体阐明），换成这种形式之后，整个 Store 层也清晰明了，并且不会随着业务迭代而变得越来越简单。

重构后，咱们只须要用上面短短几行代码就能够实现：

每个视图组件（A/B/C/D）拿到调用“静音”的回调后果，本人做更新界面的操作。

这样子，由原来的一处代码须要关注 N 处，到当初只须要一处代码关注一处，大大降低了代码的复杂度。

三、数据全局化

举一个例子：在非父子组件之间共享传递一些状态，咱们会应用状态晋升来解决这个问题。然而如果此时组件之间的嵌套过深，那么两头通过的组件都会帮忙传递这些无用的 props，且如果须要传递参数或者减少 props，都须要批改 A、B、两头组件 * n 个中央。

那么这时候，咱们就会将这些状态放到全局 redux 中。但这样，又会引来其余的问题，对于一些长期放弃的状态，比方在中后盾常见的场景：A 组件管制同层弹窗组件 E 的显示暗藏状态，而这些状态对于用户来说，并不需要保留，是一次性的。

此时因为两头逾越的组件过多，咱们将他放到了 redux 外面去，长此以往，redux 中的 action 越来越多。缓缓的，咱们每次批改都须要确认他是否也一样影响了其余组件（实际上，这个 action 只会在这个模块中应用到，其余模块都毋庸关注）。

对于 Redux 派的数据流治理，都是中心化的。看了大部分的中后盾产品，须要全局共享的数据并不多，个别只有用户 user 信息。在这个背景下，咱们看向 mobx，他人造反对多个 store。那怎么去设计 store？

高内聚对于晋升我的项目的可维护性天然是一个坏事，然而如果不管制好粒度，也容易引起问题。比方，咱们严格依照 React 官网的领导意见：如果多个 Component 之间要产生交互, 那么状态(即: 数据) 就保护在这些 Component 的最小公约父节点上

那么依照这种划分，咱们的程序会呈现 成十上百个公约节点，随着我的项目的迭代后退，已经只是 A, B 之间共享，前面变成了 A,B,C 共享，最大公约节点又须要向上晋升，在多人合作的状况下，太多的晋升和变更很容易引起我的项目的不稳固，所以，咱们划分了上面三层 store，最小粒度的 store 为模块 store。

映射到具体我的项目中的 Store 图如下：

四、畛域模型 DDD

咱们如何去设计 Store？咱们应用了畛域驱动设计，也就是 DDD。

为何须要 DDD 呢？

• 在传统的前端开发流程中，前端和业务是通过视觉稿来分割的，一旦视觉稿产生变更，就象征大量的批改老本。目前产品到了 1～n 阶段，视觉稿需要稿的变动是必然的。
• 一个简单的产品，是由多人合作的，如果大家都是依照视觉稿去设计 Store，那么反复的逻辑会越写越多，前面技术债也越来越大。
• 贴合业务

如果咱们采纳 DDD，比方咱们形象一个畛域模型「文件」，在这外面，寄存文件的相干操作：「批改文件名，删除文件，挪动文件……」，有了这样一个稳固的畛域模型，视图层只须要实现视觉稿和组装业务逻辑，具备很强的灵活性，就如同搭积木一样，底层的畛域模型不须要变动，只须要改变交互变更或视图。极大晋升了开发效率和维护性。

举个例子，随着我的项目的迭代，对于文件的相干操作：删除、挪动等这些曾经积淀在畛域模型中了，如果此时产品变更，删除的入口产生了变动，或者是减少了一个新的删除入口，那咱们只须要批改完视图组件，而后在须要调用的中央调用下对应畛域的 action 即可

依照畛域的划分，Store 之间的界线也更加清晰。

留神：DDD 不是一个框架，而是一种架构思维，所以前端在开发之前，要先细化需要，设计好 Store 再进行开发。

我的项目中已积淀的畛域

改良点：依据 Mobx 官网领导倡议，除了页面一些涣散的状态，还会依据整个业务个性积淀一些通用的畛域模型，这些能够依据不同页面须要，注入到对应的 Page Store 中去。

畛域驱动设计这个理念曾经在咱们的业务中摸打滚爬了几个月，参加开发的同学都说好，在前端人力瓶颈大的状况下，后盾同学也参加进来写 Store，Store 与 视图同步并行开发，从串行开发到并行，极大晋升了整体的开发效率。

技术选型

写了这么多，新的零碎架构须要以下几个个性，能力让零碎走得更快更远：

• 正当的分层，UI / 逻辑拆散
• 简单我的项目 Store 的粒度细化很重要，畛域模型 DDD
• 回绝模版代码，晋升开发效率
• 面向未来 & 兼容旧代码 — 反对 hook & class
• 更好的 ts 反对

咱们冀望领有这些个性，而后一个一个比照。

unstated-next

1. 不晓得要写多少 provider，写法过于灵便，组织成畛域模型须要大量革新（在一个小我的项目试验过，最初随着业务越来越简单，放弃了。）
2. 旧的业务逻辑须要革新，一旦遇到 class 的状况，就又要回到旧的写法，在疾速迭代业务的时候，是不可能停下来一个一个全副革新成 hook 的。

redux

1. 大量的模版代码
2. 过于灵便的 Redux 调用（网状调用）
3. TS 反对革新老本大

为什么抉择 mobx？

✅大量 / 无 模版代码

✅面向未来 & 兼容旧代码 — 反对 hook & class

✅很不便地对业务进行分层，很不便地设计畛域模型

✅TS 反对 0 老本

✅人造反对多态 Store，去中心化更不便

✅须要显示 DI，解决了网状调用的问题

对于 Mobx 的毛病业界也说了很多，无非就是以下几个点：

1. 状态能够随便被批改 — 解决方案：开启严格模式限度，且只可在 Store 中批改，不可在视图组件批改
2. 不反对 hook，mobx-react-lite 已反对

综合下面种种原因，如果为了这些个性，从新去造一个轮子或者革新一个轮子，老本远远比间接借助 mobx 的力量更大。所以，在调研了多种数据流计划之后，抉择了 Mobx 来撑持咱们下面的架构。

总结

没有最好的技术计划，只有最适宜业务的技术计划。咱们从一个一个“业务痛点”推导出一套解决方案，并且已在理论我的项目中跑了几个月，也取得了不错的成果。

作者：被单
原文链接
本文为阿里云原创内容，未经容许不得转载