EnterpriseApplication

2014年3月24日

在本世纪初,我开始写我的书企业应用程序架构的模式。我在写这本书时遇到的一个问题是如何给它命名,或者更确切地说,我所写的那些软件系统应该怎么称呼。我一直意识到,我的软件开发经验一直集中在一种特定形式的软件上——像医疗记录、外汇交易、工资和租赁会计。它们与打印机内的嵌入式软件、游戏、飞行控制软件或电话开关非常不同。我需要一个名称来描述这些类型的系统,并确定了术语“企业应用程序”。

正如我经常说的,这个术语没有正式的定义。然而,企业应用程序有一些共同的特征。

企业应用程序通常有大量的持久数据,通常由某种数据库管理系统管理。通常这个数据库是关系型的,但是我们越来越多地看到NoSQL的替代品。这些数据通常比处理它的应用程序持续时间更长,也更有价值。

数据被并发地访问和操作。数量差异很大,内部应用程序可能有几十个用户,但是面向客户的web应用程序很可能有数万个用户。尽管并发性水平很高,但许多企业应用程序开发人员并没有过多考虑经典并发编程的关键区域、竞争条件和其他元素。相反,他们把自己的想法建立在数据库或专门的事务管理工具管理的事务之上。

企业应用程序有这么多数据大量的用户界面屏幕来处理它。通常在不同的上下文中以不同的方式操作相同的数据。用户从普通用户到偶尔用户各不相同,因此界面需要匹配不同层次的熟悉度。还有大量的离线(批处理)处理很容易被遗忘。

即使您正在构建一个全新的企业应用程序,也不能孤立地这么做。相反,你需要这样做与其他企业应用程序集成。这些系统是由各种团队构建的,一些来自向许多客户销售产品的供应商,另一些则是仅为您的组织内部构建的。这些应用程序将在几十年的时间里以各种不同的技术编写而成,其中一些您必须向您的母亲询问。有许多集成机制可以处理——文件交换、共享数据库、消息传递中间件。偶尔会有人试图将所有这些通信技术合理化,但它们从未完全成功,留下更多的复杂性。

即使不同的应用程序访问相同的数据,也会有相当大的影响概念上的不一致在他们之间,客户对销售组织的意义可能与对技术支持的意义大不相同。发音相同的实体在不同的上下文中有不同的字段,或者更糟的是具有相同名称但不同含义的字段。

然后是所谓的“业务逻辑”。当你在写一个操作系统的时候,你要努力保持整个事情的逻辑性和逻辑性,以发现和实现简化,以保持软件的直观和可靠。但商业规则是现成的,如果你想改变它们,你需要召开67次会议,还要有三位副总裁退休。它们通常是一系列杂乱的奇怪的条件,以令人惊讶的方式相互作用。他们的疯狂源于一个很好的理由,每一个例子都是推销员可以通过提供一些特殊的一次性条件来完成特定的交易。这样做一千次,你有复杂的业务“不合逻辑”这是许多企业应用程序的核心。

企业应用程序可以很大也可以很小。讨论通常集中在大型、复杂的应用程序上,但是对于需要快速构建的小型应用程序也存在挑战。大系统出现问题时会产生很多噪音,而小系统的累积效应会对企业的健康状况产生令人吃惊的影响。

为事物起名字总是很棘手的。你需要使用最少的词汇,并希望它们在读者的脑海中触发正确的内涵,这样你就不必不断提醒他们定义的含义。总的来说,我对自己的选择相当满意,但自从我完成了这本书,企业这个词的内涵就不太适合我的用法了。

本书出版后出现的一个问题是,“企业”现在通常是指大型的、信誉良好的公司。人们想到的是通用电气(ge)或西门子(Siemens),而不是Facebook、Etsy或一家拥有100名员工、生产定制t恤的公司。但根据我上面的定义,即使是小型初创企业也依赖于我称之为企业应用程序的软件。因此,尽管Ruby on Rails社区已经结束了对企业的侮辱,但我还是将Ruby on Rails称为构建企业应用程序的框架BaseCamp企业应用程序的经典示例。(别告诉他是我说的,不然他会把我变成车顶装饰品的。)

这些关于“企业”的内涵让我思考我们是否需要一个不同的术语。当我写EAA的P的时候,我的工作标题是“信息系统架构”,但是我们觉得“信息系统”有它自己不受欢迎的古老技术的内涵。我想我可以真正复古地使用“数据处理”,但总体而言,“企业应用程序”似乎仍然是我能想到的最好的术语。

本文是改编自企业应用的定义中的介绍监管局的P。