layout: post title: 前端架构 101（六）：整洁（Clean Architecture）架构是归宿 modified: 2020-06-16 tags: [javascript] image: feature: abstract-3.jpg credit: dargadgetz creditlink: http://www.dargadgetz.com/ios-7-abstract-wallpaper-pack-for-iphone-5-and-ipod-touch-retina/ comments: true
如果你对整洁架构（Clean Architecture）有所了解的话，回想一下我们前几篇中描述的内容，你会发现整洁架构对前端，对 MVP 来说也是同样适用的。
关于什么是整洁架构完全可以通过阅读 Uncle Bob 原版图书中文版《整洁架构之道》来了解，或者可以通过阅读他的一个简短版本博客 The Clean Architecture 一探端倪。但我还是推荐阅读图书，图书全面而且浅显易懂，没有和某一门编程语言强行绑定，即使你没有后端背景也能流畅的通读下来。出于篇幅的考虑，在这里我只取一瓢，摘取一个契合于我们前端架构的知识点以做说明，就是模块间的依赖关系
这篇文章里更多的是告诉你 what（结论），而不是 why（为什么需要这么做）。因为 why 这件事需要更多的上下文来解释，这也是我为什么推荐你阅读原书的另一个原因。
为了便于说明，我也把上次的 MVP 流程也放在这里
我们可以将我们的应用大致划分为三类模块：UI、Service Layer (Presenter)，Business Model。这么划分不仅是直觉上告诉我们应该怎么做，更重要的是这三大类的模块的变化频率是不同的，这也是我前文中说的 axis of change.
变化频率最高的是 UI。这里的变化频率不仅仅指的是我们实际上修改代码的次数，还包括它可以”被替换的程度"。什么意思呢？想象一下目前你正在编写的任何前端应用，关于视图的渲染可能使用的是 React, Angular, 甚至还可能只是 Node.js 的命令行而已。但无论视图层的框架是什么，这个应用的核心功能是不会变的，如果它是一个计算器，不同视图框架编写的不同之处无非在于，用户是通过 React 的输入框、 Angular 输入框还是电脑终端输入需要计算的数值。
变化频率次高的是 Service Layer，也就是用户用例，最后才是 Business Model。Service Layer 通常起的是编排作用，你也可以简单理解为流程控制，它通过调用各个 Business Model 来完成用户的一次交互，相信你完全可以理解流程的更改是比较频繁的。而至于 Business Model，则是不会轻易更改的，或者说修改起来是非常慎重的。想象税务系统或者移民系统中的每一个业务领域，每一个规则都和法律法规相关联，有的和公司的政策和盈利模式相关联，是不能随意修改的。
还是想强调我描述的其实是一种相对情况，你在实际过程中可能你的 Service Layer 和 Business Model 会有相同的修改频率。有时候这种情况是正常的，但有时候是则是危险的信号。
什么是危险的信号？
我们想象一段用计算星座的 React 组件代码：
function ZodiacComponent({ year, month, day }) {
const result = zodiacService.get(year, month, day);
return <div>{result}</div>
}
假设我们现在需要把UI重构，用 Angular 改写：
@Component({
selector: 'app-zodiac',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
export class AppComponent {
@Input() year: number;
@Input() month: number;
@Input() day: number;
result:number
constructor(private zodiacService: ZodiacService) {
this.result = this.zodiacService.get(year, month, day);
}
}
不难看出无论是在 React 还是 Angular 中最核心的功能在于 zodiacService.get方法，它通过传入的年、月、日来计算用户的星座。但无论你用什么样的UI框架对应用视图进行重写，这部分的计算逻辑是不需要发生变化的。这是我们的核心业务逻辑。
业务不需要关心 UI。这是想当然的事情。
但如果你在重写应用时发现修改 UI 的同时也需要修改业务逻辑，这个可能就会有问题了。这么做是完全可能的，例如在 React 中你这么向 zodiacService 的 get方法传递的不是年月日，而是组件信息：
class ZodiacService {
get(componentRef) {
const year = componentRef.current.querySelector('#input-year').value;
const month = componentRef.current.querySelector('#input-month').value;
const day = componentRef.current.querySelector('#input-day').value;
}
}
很显然，这样的get方法因为和 React 组件机制进行了强绑定，当我们需要使用 Angular 重构时，这一部分代码无法被 Angular 组件所使用。
这只是其中一种模块与UI产生关联的情况，在现实代码中，我们很多时候都会“一不小心”对UI产生了依赖。
UI与业务逻辑可能算是极端的情况，但是 Service Layer 和 Business Model 之间呢，Service Layer 和 UI 之间呢，相邻层之间更容易产生相互依赖和耦合。耦合在代码中的表现症状可能是 bad smell 中的 “散弹式修改”，也可能是“依恋情结”，“发散式变化”。但它们背后的原因根本原因其实是模块之间产生了不合理的依赖。
所以文章最开始的（圆环套圆环的）整洁架构图中，不同层（圆环）之间的依赖关系是有方向性的，并且方向是指向内部的，即每一个圈的内部都对它的外部一无所知，这里的一无所知包括函数、变量等等。所以我们能看到 Business Model 不知道调用它的 Service Layer 究竟完成的是什么样的流程，它也更不知道最外层的 UI 使用的是什么框架。
这个思路不仅对于前端是适用的，对于其他类型的应用也同样是适用的。只不过对于后端应用来说，产生的交互的，可以被替换的不仅是前端，还可是API。
最为这个系列的最后一篇，在之前谈论了那么多理论之后，我想正面的回答一个很多人心中应该会有的问题：所有的组件、所有的应用，都必须按照 Flux、MVP、整洁架构来开发吗？
如果一定要按照是或者不是来回答的，答案一定是不是。
更准确的答案是：依照情况而定。
比如一个加载数据同时渲染在列表上的组件：
function UserList() {
const [data, setData] = useState([])
useEffect(() => {
requestUserList().then(response => setData(response))
}, []);
return {data.map(item => <User data={item} />)}
}
这个组件可以再做拆分吗？当然可以；但是它还有必要拆分吗？我认为没有。
这又要回到我们第一篇中说的，本质上所有的设计，都是为了非功能需求。尤其是为了降低今后的维护成本。首先这段代码是极其简单的，这非常好，降低了我们系统的复杂性；其次如果你认为这段代码今后的维护成本在可控的范围之内，那么它其实就没有再进行拆分的必要。
那你可能又会问了，什么时候该拆分呢？我想回答：当它该拆分的时候。
这不是废话吗！
问题其实在于，我很难给出你一个精确的标准，比如当 XX 到达 XX 时，当 XX 遇到 XX 情况时就应该拆分；又或者说，拆分的标准太广了，Martin Fowler的《重构》或者是是 Uncle Bob 的 《整洁代码之道》都可以作为拆分的标准。
这个没有标准的标准，完全取决你的个人决策，恰恰也是最考验功力的地方，这也是最能体现你价值的地方。
你可能会喜欢