企业级 Web 开发的挑战

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

本文翻译自土牛Halil ibrahim Kalkan的《Mastering ABP Framework》，是系列翻译的起头，适合ABP开发人员或者想对ABP框架进行深入演进的准架构师。

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

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

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

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

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

所有这些决策都不是一件容易的事情。

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

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

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

我们先思考一个问题：为什么我们在构建软件时会重复自己呢？

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

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

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

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

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

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

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

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

虽然每个应用系统是独特的，而且其价值来自于独特性，但是每个企业系统都有一些基本的配套需求。

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

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

所有这些常见的需求都可以从头开始构建，但是这需要我们耗费巨大的成本和精力，如果你的团队没有经验丰富的架构团队，还不一定能完成得很好。如果这些功能不是公司的主要价值，我们完全可以考虑开源社区预构建的模块和库，并根据特定的要求进行定制。

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

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