前后端一体化：前后端分离将死？ _应用

不过呢，我们还要使用语言重写部分 Java 代码，那么我们为什么不要/重写一切呢？

文章插图
引子 2： /重写一切
遗憾的是，使用编写后端应用（BFF、胶水层除外），在大部分的大公司是比较难的。内部的生态链和运维影响了技术决策，使用 C++ 不香吗，使用会存在无人在背后支持。
纯 Node.js 后端应用
在过去的几年里，我建议：小公司的后端应用不要使用/编写，因为运维、监控、APM 等生态尚不够完善。小公司应该优先投资于业务领域，在基础设施的投入见效比较短，除非能控制好开发人员的流动性。
不过，不管怎样，已经有大量的小公司因为人力成本的原因，已经使用上了 Node.js 来开发后端应用。
应用
而随着系生态的完善，基础设施已经不是会成为小公司的负担，我便觉得这是一个好的时机。不过，我指的是采用架构，而非自建系生态。不仅帮助小企业解决了基础设施的问题，还能为小企业降低软件运维成本。一旦企业做大之后，也可以自建采用等开源方案解决的供应商锁定问题。
不论是 Node.js 后端应用还是应用，因为使用的是同一种语言，我们可以轻松地在前后端之间共享代码，可以是 Git 、NPM 包、远程等等的方式。

文章插图
引子 3：纯编译到
市面上有各种各样支持to js 的语言、框架，诸如于 .js、Scala.js、.js 等等。
对于小前端的应用来说，这种架构非常的不错。它相当于是渐进式的系统架构方案，当前采用了主流的前端框架，而非传统的后端渲染机制，并统一了技术栈，降低了组织内部的学习成本。不过，它带来额外的调试因素，毕竟每多一层封装，系统的复杂度就需要 * 2 。
而为了让框架的使用者支持不同的框架 React、、Vue ，这个框架还需要提供这些框架的 bind 或者是，以提升框架使用者的幸福感。
但是，我们的挑战依然是复杂的前端应用，以及它难以消除交互的复杂度。
引子 4：共享领域模型/模式库

文章插图

文章插图
开始之前，我不得不强调一，领域模型是一种包含数据和行为的抽血模型。
编译到是一种轻前端的方案，而对于重前端的项目来说，它们完成可以采用一种新的模式：共享领域模型。即将领域模型作为模式库，提供给前后端一起使用。即，我们只需要编译所需要的部分。
这在我使用了的多平台技术（）重写了 Chapi 的层之后，我意识到了这是一个非常迷人的方案。我即使用在前端代码中使用 Chapi 的领域模型，我还需要在后端的代码中使用这套模型。原先，我需要手动翻译一行行代码，现在我并不需要这样的一个步骤。只需要在 pom.xml、build. 或者是 .json 中引入依赖及其对应的版本即可。
在引入了这部分的代码之后，我们再关注于 UI 交互部分即可。