企业级 Web 开发的挑战

本文翻译自途牛哈利尔的《ABP》，是一系列翻译的开篇，适合想要进一步演进ABP框架的ABP开发者或准架构师。

在深入研究 ABP 框架之前，我想介绍开发现代企业 Web 解决方案所面临的挑战，以了解我们为什么需要 ABP 框架。让我们从大局开始：

架构挑战

在开始编码之前，我们需要为解决方案打下基础。这是构建软件系统最具挑战性的阶段，在此阶段做出的任何决定都会影响应用程序的整个生命周期。

有一些常见的、众所周知的系统级架构模式，例如单体、模块化和微服务。不同的架构选择会决定后续团队的组织架构、部署和扩展，所以我们应该尽量根据需求做出最佳选择。

此外，命令和查询职责分离 (CQRS)、领域驱动设计 (DDD)、分层架构和清洁架构等软件开发模型将决定您的底层代码结构。

在这个阶段，我们还需要决定将使用哪些语言、框架、工具和库。

这些决定都不容易。

我们可以问自己一个问题：我们团队中的软件架构师和开发人员是否具备这些能力和运营能力？

现实情况是，并非所有团队成员都具有高水平的经验和知识。我们需要战略性地制定标准规范，并在战术上实践最佳编码。

重复轮子！

不要重复自己 (DRY) 是软件开发的关键原则。

让我们从一个问题开始：为什么我们在构建软件时会重复自己？

身份验证是每个软件都需要的功能，包括单点登录、基于令牌的身份验证、社交登录、双重身份验证、忘记/重置密码、电子邮件激活等等，几乎所有软件项目或多或少都有类似的身份验证需求。与其从头开始构建所有这些，不如重用现有的解决方案（例如云服务），这些解决方案在实用性和安全性方面都更加稳定和成熟。

还有一些非功能性需求，例如异常处理、验证、授权、缓存、审计日志和数据库事务管理，这些都是代码重复的来源。这些关注点称为横切关注点，应该在每个 Web 请求中处理。

当您集成到 Redis 和 Redis 等第 3 方系统时，您通常会创建抽象和装饰器。通过这种方式，您的业务逻辑与这些基础设施组件隔离开来。此外，您不会在整个系统中重复相同的连接、重试、异常处理和日志记录逻辑。

拥有一个预先构建的基础架构来自动执行这些重复性任务可以节省您的开发时间，这样您就可以专注于您的业务逻辑。

构建 UI 基础

用户界面 (UI) 也是应用程序的基础。过时且无法使用的 UI 并没有那么吸引人，即使它在幕后具有出色的商业价值。

虽然每个应用的 UI 功能和要求各不相同，但一些基本结构是通用的，例如警报、按钮、卡片、表单元素、选项卡和数据表。您可以使用 HTML/CSS 框架，例如 、Bulma 和 Ant，而不是为每个应用程序创建一个设计系统。

几乎每个 Web 应用程序都有响应式布局、主菜单、工具栏、页眉和页脚、自定义颜色等。你需要为你的应用页面和组件实现一个基本的 UI 工具包。这样，UI 开发人员可以创建一致的 UI。

到目前为止，我们已经介绍了一些常见的基础架构要求，这些要求大多独立于任何业务应用程序。下面讨论常见的业务需求。

实现常见的业务需求

虽然每个应用系统都是独一无二的，其价值来自于唯一性，但每个企业系统都有一些基本的支持需求。

基于权限的授权系统是这些基本要求之一。它用于控制应用程序的用户和客户端的权限。如果你想自己实现，你应该创建一个端到端的解决方案，包括数据库表、授权逻辑、权限缓存、API 和 UI 页面。但是，这样的系统非常通用，可以开发为可复用的模块，可供多个应用程序使用。

此外，许多系统需要审计日志报告、租户和订阅管理（针对 SaaS 应用程序）、语言管理、文件上传和共享、多语言管理和时区管理等功能。除了预先构建的应用程序功能外，可能还有一些低级要求，例如实现软删除模式和在应用程序中存储二进制大对象 (BLOB) 数据。

所有这些常见的需求都可以从头开始构建，但这需要我们花费大量的金钱和精力，而且如果你的团队没有经验丰富的架构团队，可能做不好。如果这些功能不是公司的主要价值，我们可以充分考虑开源社区预建的模块和库，并根据具体需求进行定制。

结束

如果你也在学习ABP，有问题咨询，欢迎加入ABP的QQ群（免费）

@ >

或加入我的知识星球（收费），体验更及时、更全面的服务：