在前端开发过程中，你有没有遇到过由于代码交互太多太重时，想改动一行代码“牵一发而动全身”；使用框架很爽，可框架绑定应用却很麻烦？那么如何解决呢？
你需要“前端整洁”。
前端的恶梦
在我最近的一个项目里，我使用了 Angular 和混合应用技术编写了一个实时聊天应用。为了方便这个应用直接修改，无缝地嵌入到其它应用程序中。我尽量减少了 Component 和 Service 的数量。
然而，由于交互复杂 Component 的数量也不能减少。随后，当我们完成了这个项目的时候，主要的组件代码差不多有 1000 行。这差不多是一个复杂的应用的代码数。在我试图多次去重构代码时，我发现这并不是一件容易的事：太多的交互。
导致了 UI 层的代码，很难被抽取出去。我还能做的事情是将一些业务逻辑抽取出来，只是怎么去抽取了？这成了我的一个疑惑。
MVP 嘛，逻辑不都是放到 Presenter 里，还有其它的招吗？

AVR is Evil
Angular、Vue 和 React 都是一些不错的框架，但是它们都是恶魔，因为我们绑定了框架。我们可以很快地从一个 React 的框架，迁移应用到其它类 React 框架，诸如 Preact；我们可以从一个类似于 Vue 的框架，迁移应用到其它类 Vue 的应用。但是我们很难从 React 迁移到 Angular，又或者是 Vue 迁移到 Angular。
万一有一天某个框架的核心维护人员健康状况不好，那么我们可能就得重写整个应用。这对于一个技术人员/Tech Lead/项目经验/业务人员来说，这种情况是不可接受的。
所以，为了应对这些框架带来的问题，我们选择 Web Components 技术，又或者是微前端技术，从架构上切开我们的业务。但是它们并不是银弹，它们反而是一个累赘，限定了高版本的浏览器，制定了更多的规范。
与此同时，不论是微前端技术还是 Web Components，它们都没有解决一个问题：框架绑定应用。
框架绑定应用，就是一种灾害。没有人希望哪一天因为 Java 需要高额的付费，而导致我们选择重写整个应用。

组件化及 Presenter 过重
应对页面逻辑过于重的问题，我们选择了组件化。将一个页面拆分成一系列的业务组件，再进一步地对这些业务组件进行地次细分，形成更小的业务组件，最后它们都依赖于组件库。
可是呢，细化存在一个问题是：更难以摆脱的框架绑定。与此同时，我们大量的业务逻辑仍然放置在 Presenter 里。我们的 Presenter 充满了大量的业务逻辑和非业务逻辑：
页面展示相应的逻辑。诸如点击事件、提交表单等等。
状态管理。诸如是否展示，用户登录状态等等。
业务逻辑。诸如某个字符串，要用怎样的形式展示。
数据持续化。哪些数据需要存储在 LocalStorage，哪些数据存储在 IndexedDB 里？
为了应对 Presenter 过重的问题，我们使用了 Service 来处理某一块具体的业务，我们使用了 Utils、Helper 来处理一些公共的逻辑。哪怕是如此，我们使用 A 框架编写的业务逻辑，到了 B 框架中无法复用。
直到我最近重新接触了 Clean Architectrue，我发现 Presenter 还是可以进一步拆分的。

整洁的前端架构
Clean Architecture 是由 Robert C. Martin 在 2012 年提出的。最早，我只看到在 Android 应用上的使用，一来 Android 开发使用的是 Java，二来 Android 应用有很重的 View 层。
与此同时，在 7 年的时间里，由于前后端的分离，UI 层已经从后端的部分消失了。当然了，你也可以说 JSON 也是一种 View（至少它是可见的）。尽管，还存在一定数量的后端渲染 Web 应用，但是新的应用几乎不采用这样的模式。
但是，在 9012 年的今天，前端应用走向了 MV* 的架构方案，也有了一层很重的 View 层。类似于过去的后端应用，或者后端应用。相似的架构，也可以在前端项目中使用。

整洁架构
Robert C. Martin 总结了六边形架构（即端口与适配器架构）：DCI （Data-Context-Interactions，数据-场景-交互）架构、BCI（Boundary Control Entity，Boundary Control Entity）架构等多种架构，归纳出了这些架构的基本特点：
框架无关性。系统不依赖于框架中的某个函数，框架只是一个工具，系统不能适应于框架。
可被测试。业务逻辑脱离于 UI、数据库等外部元素进行测试。
UI 无关性。不需要修改系统的其它部分，就可以变更 UI，诸如由 Web 界面替换成 CLI。
数据库无关性。业务逻辑与数据库之间需要进行解耦，我们可以随意切换 LocalStroage、IndexedDB、Web SQL。
外部机构（agency）无关性。系统的业务逻辑，不需要知道其它外部接口，诸如安全、调度、代理等。
如你所见，作为一个普通（不分前后端）的开发人员，我们关注于业务逻辑的抽离，让业务逻辑独立于框架。
而在前端的实化，则是让前端的业务逻辑，可以独立于框架，只让 UI（即表现层）与框架绑定。一旦，我们更换框架的时候，只需要替换这部分的业务逻辑即可。

为此，基于这个概念 Robert C. Martin 绘制出了整洁架构的架构图：
Clean Architecture
如图所示，Clean Architecture 一共分为四个环，四个层级。环与环之间，存在一个依赖关系原则：源代码中的依赖关系，必须只指向同心圆的内层，即由低层机制指向高级策略。其类似于 SOLID 中的依赖倒置原则：
高层模块不应该依赖低层模块，两者都应该依赖其抽象。
抽象不应该依赖细节，细节应该依赖抽象。
与此同时，四个环都存在各自核心的概念：
实体（Entities），又称领域对象或业务对象，实体用于封装企业范围的业务规则。
用例（Use Cases），交互器，用例是特定于应用的业务逻辑。
接口适配器（Interface Adapters），接口适配器层的主要作用是转换数据。
框架和驱动（Frameworks and Drivers），最外层由各种框架和工具组成，比如 Web 框架、数据库访问工具等。