使用微型用户界面扩展传统 Web 应用程序

许多人开始了解微型用户界面或微型前端（这并不是什么新鲜事）。

我在关于微服务架构的文章中，着重指出了许多人在思考和设计微服务时存在的一个重大问题。在大多数微服务设计中，用户界面层并未被视为服务的一部分。

采用这种设计，最终会将用户界面层与所有服务耦合在一起。

团队耦合

通过将各项服务耦合到单一的整体式用户界面中，您实际上消除了使用微服务设计的最大优势：

团队能够自主运作，并独立于其他团队部署其工作成果。

换句话说，微服务架构实现了团队之间的松耦合。

但是，如果用户界面问题得不到解决，团队之间就会在用户界面层面发生冲突。

相反，我们希望采用 SOA 领域多年来一直在做的事情：让每个团队都能拥有自己的 UI。

微型用户界面

微型用户界面是一种方法，其中每个团队或服务都会创建他们自身功能所需的用户界面组件。

最终，团队在整合工作时必须协调彼此的努力。

尤其是在面向用户的网页上，我们需要同时展示来自多个团队的功能。这是不可避免的。

然而，耦合程度极低。

该方法是为每个服务创建一系列独立的组件。然后，将这些组件组合到用户界面层中。

遗产的麻烦

许多开发人员不仅需要维护现有的遗留系统，还要不断添加新功能！

这些系统可能由于多年来团队缺乏设计架构、规划、技术战略或技能而失控。

总之，向系统中添加新功能可能非常困难。

几乎没有自动化测试：如何确保没有破坏任何现有代码？

是否应该修改现有代码？

新代码到底应该放在哪里？

这些问题很可能难以回答，因为大多数遗留系统都很难进行逻辑推理。

使用微型用户界面扩展传统应用程序

我一直在使用一种源自 SOA 领域的技术来增强遗留系统。

这取决于你需要添加哪种类型的更改。

如果您需要添加，例如，屏幕上的新部分或全新的网页，那么这可能对您有用。

案例研究

以下是我成功运用这种方法的一个例子。

我当时正在开发一个系统，该系统结合了以下几个方面：

• 面向用户的 VB.NET Web 应用程序
• 内部 VB.NET Web 应用程序
• 面向公众的产品营销网络应用程序
• .NET Framework Web 应用程序用于渲染初始网页
• 100% 自主开发的 JS 框架，包含 100% 自主开发的组件（使用 jQuery）。
• .NET Web API 将与自定义的 JS 框架交互，以返回 JSON、HTML 以及介于两者之间的任何格式。
• 它们之间共享的各种库
• 一切背后都隐藏着一个庞大的共享数据库。

还有一些系统缺失，但这应该能让你有个大致了解。

哦，对了，根本没有自动化测试。任何地方都没有。

已请求添加新功能！

您可以想象，一些现有功能的逻辑分散在所有这些系统中，其中很多逻辑也存在于数据库中。

这个定制的JS框架也极其难用。原本几天就能完成的工作，却耗费了数周甚至数月的时间。

我决定尝试一种新的方法来构建新功能。

制定策略

我认为有很多问题需要解决。与本文相关的是，以下是针对最紧迫问题的解决方案：

• 停止使用自定义的JS框架，因为它拖累了整个系统。
• 为所有新功能启用自动化测试
• 将业务/领域逻辑封装在一个可供系统所有不同部分共享的公共区域中。

随着时间的推移，我逐渐开始运用领域驱动设计的方法和技术来改进产品。这需要大量的学习，也需要培训其他开发人员。

以下是新功能设计概念的大致草图：

当然，这只是改进工作的第一步，而改进工作是一个庞大的过程。

以上内容均不包括我一直在主导开发的新移动应用程序和 API 😅。

如何整合？

一些现有功能需要改进。采用这种设计，我们可以尽可能地将所有新代码都直接放在领域项目中。现有功能只需调用领域项目并根据需要使用即可。

通过使用重构技术，我们能够将现有逻辑提取到领域层，改进现有功能并为其添加测试！

但如果您需要开发全新的功能或产品呢？

这时微型用户界面就派上用场了。

与其直接集成到现有的遗留代码库中，我们可以尽可能多地将其构建到：

1. 领域项目（包括使用领域驱动设计方法和编写可测试代码）
2. 直接与领域逻辑交互的专用 UI​​ 组件

下面这张图展示了它在逻辑上的样子：

实际上，它的技术实现方式如下：

在这种情况下，我们尽量减少增加基础设施和复杂性。

各特征的数据流如下：

1. Vue.js 组件位于共享 CDN 上。
2. 这些组件向现有的 .NET MVC 应用程序发送 HTTP 消息。
3. MVC应用程序被拆分成多个功能文件夹。每个功能本质上都是一个类似“迷你应用程序”的结构。
4. 每个 HTTP 处理程序只是将请求传递给域级命令或查询处理程序。

关于有限上下文

在这种情况下，每个新功能的核心都被放在了同一个 .NET 库中。这是由一个负责管理所有系统的小团队完成的。

但是值得注意的是，从逻辑上讲，这本质上是一种类似 SOA 的方法。

这些新特性中有些可能属于限界上下文。如果是这样，那么它们非常适合成为微服务（如果需要的话）或模块化单体架构中的一个模块。

上面的图表看起来与本文开头关于拥有独立用户界面的微服务的图表非常相似。从逻辑上讲，它们是同一回事。

没有食谱

每个团队都不一样。每种情况都不一样。

目前，我正在帮助这个团队将其中一些问题拆分成单独的模块，作为有界上下文。

但是，对于这些大型遗留系统来说，这是一个漫长的、循序渐进的迭代改进过程！

你必须利用现有资源，并面对以下现实：

• 基础设施限制
• 技术限制
• 业务限制
• 开发人员技能限制
• ETC。

这需要一定的思考和设计能力。

好处

毫无疑问，每个人，尤其是商界人士，都看到了其中的好处。

• 能够在几天内构建出原本需要数周甚至数月才能完成的新功能，是一项巨大的胜利。
• 能够将自动化测试应用于领域逻辑，可以产生更可预测的行为，并允许安全地重构。
• 将更改限制在特定区域内意味着降低错误导致软件中不相关部分出现故障的风险。
• 将 Vue.js 等新技术集成到传统技术中，能够带来更丰富的用户体验，并在招聘新开发人员时成为一大卖点。

后续步骤

您是否正在处理一个非常难以维护的遗留应用程序？

企业是否想要开发新功能，但目前现有的代码和设计却造成了很大的阻碍？

本文中介绍的方法或许会有帮助。

有时候，有专家帮助你围绕这类变化和方法制定策略，会非常有帮助，也能节省时间。

如果您需要帮助，可以联系我。

下次再见！