企业应用

在本世纪初，我撰写了《企业应用架构模式》一书。在写作过程中，我遇到的一个问题是如何给这本书命名，或者更确切地说，如何称呼我所写的这类软件系统。我一直意识到，我的软件开发经验一直集中在一类特定的软件上，例如医疗保健记录、外汇交易、工资单和租赁会计。这些与打印机、游戏、飞行控制软件或电话交换机中的嵌入式软件截然不同。我需要一个名称来描述这类系统，最终选择了“企业应用”一词。

正如我经常说的那样，这个词没有正式的定义。然而，企业应用确实有一些共同的特征。

企业应用通常有大量的持久化数据，通常由某种数据库管理系统管理。通常，此数据库是关系型的，但我们越来越多地看到 NoSQL 替代方案。这些数据通常比处理它的应用程序更持久、更有价值。

这些数据会被并发访问和操作。数量差异很大，内部应用程序可能有几十个用户，但面向客户的 Web 应用程序很容易拥有数万个用户。尽管并发程度很高，但许多企业应用开发人员并没有过多考虑临界区、竞争条件和其他经典并发编程元素。相反，他们基于数据库或专门的事务管理工具管理的事务构建了他们的思维。

由于数据量巨大，企业应用有大量的用户界面屏幕来处理这些数据。通常，相同的数据会在不同的上下文中以不同的方式进行操作。用户从经常使用到偶尔使用不等，因此界面需要匹配不同的熟悉程度。此外，还有大量的离线（批处理）处理很容易被遗忘。

即使您正在构建一个全新的企业应用，您也不是孤立地进行的。相反，您需要与其他企业应用集成。这些系统由各种团队构建，有些来自向许多客户销售产品的供应商，有些则是在内部构建的，仅供您的组织使用。这些应用程序将在过去几十年中使用各种不同的技术编写，其中一些您可能需要询问您的长辈。有许多集成机制需要处理，例如文件交换、共享数据库、消息中间件。每隔一段时间，就会有人尝试将所有这些通信技术合理化，但他们从未完全成功，反而留下了更多的复杂性。

即使不同的应用程序访问相同的数据，它们之间也存在相当大的概念差异，客户对销售组织的意义可能与对技术支持的意义截然不同。相同实体在不同的上下文中具有不同的字段，或者更糟糕的是，具有相同名称但含义不同的字段。

然后是所谓的“业务逻辑”。在编写操作系统时，您会努力使整个系统保持逻辑性，并努力发现和实现简化，以保持软件的直观性和可靠性。但业务规则是按原样提供给您的，如果您想更改它们，则需要召开 67 次会议，并让三位副总裁退休。它们通常是一堆奇怪的条件，以令人惊讶的方式相互作用。它们的疯狂源于一个很好的理由，每一个案例都是销售人员可以通过提供一些特殊的、一次性的条件来完成特定交易的案例。这样做一千次，您就会得到许多企业应用核心的复杂的业务“非逻辑”。

企业应用可以大也可以小。讨论通常集中在大型、复杂的应用程序上，但小型应用程序也面临着需要快速构建的挑战。大型系统在出现问题时会发出很大的噪音，但小型系统的累积效应会对企业的健康产生惊人的影响。

为事物命名总是很棘手。您需要使用最少的词语，并希望它们在读者心中引发正确的联想，这样您就不必不断地提醒他们定义的含义。总的来说，我对自己的选择感到相当满意，但自从我完成这本书以来，“企业”一词已经带上了与我的用法不太相符的含义。

自这本书出版以来出现的一个问题是，“企业”现在通常指的是大型、成熟的公司。人们想到的是通用电气或西门子，而不是 Facebook、Etsy 或一家生产定制 T 恤的百人公司。但根据我上面的定义，即使是小型初创公司也依赖于我称之为企业应用的软件。因此，尽管 Ruby on Rails 社区最终将“企业”用作一种侮辱，但我还是会将 Ruby on Rails 称为构建企业应用的框架，并将 BaseCamp 称为企业应用的典型例子。（只是别告诉 DHH 我这么说，否则他会把我变成引擎盖上的装饰品。）

围绕“企业”的这些含义让我思考我们是否需要一个不同的术语。在我写《企业应用架构模式》的时候，我的工作标题是“信息系统架构”，但我们觉得“信息系统”本身就带有对老技术的贬义。我想我可以回到过去，使用“数据处理”，但总的来说，“企业应用”似乎仍然比我能想到的任何其他术语更好。