企業應用程式

本世紀初，我撰寫了我的著作《企業應用程式架構模式》。在撰寫本書時，我遇到的其中一個問題是如何為其命名，或更確切地說，如何稱呼我所撰寫的軟體系統類型。我始終意識到，我的軟體開發經驗一直專注於一種特定的軟體形式，例如醫療保健記錄、外匯交易、薪資和租賃會計。這些與印表機、遊戲、飛航控制軟體或電話交換機中的嵌入式軟體非常不同。我需要一個名稱來描述這些類型的系統，最後確定了「企業應用程式」這個詞彙。

我必須經常說，這個詞彙沒有正式的定義。然而，企業應用程式有一些共同的特徵。

企業應用程式通常具有大量的持續性資料，通常由某種資料庫管理系統管理。這個資料庫通常是關聯式的，但我們越來越常看到 NoSQL 的替代方案。這些資料通常比處理它們的應用程式更持久且更有價值。

這些資料會同時存取和操作。數字差異很大，內部應用程式可能只有數十個使用者，但面向客戶的網路應用程式很容易有數萬個使用者。儘管並發性很高，但許多企業應用程式開發人員並不太考慮臨界區、競爭條件和其他經典並發程式設計的元素。相反地，他們建立在資料庫或專門的交易管理工具管理的交易之上。

由於資料太多，企業應用程式有許多使用者介面畫面來處理它。通常，相同的資料會在不同的脈絡中以不同的方式操作。使用者從一般使用者到偶爾使用者都有，因此介面需要符合不同的熟悉程度。還有大量的離線（批次）處理很容易被遺忘。

即使您正在建立一個全新的企業應用程式，您也不會孤立地進行。相反，您需要與其他企業應用程式整合。這些系統是由廣泛的團隊所建構，有些來自銷售給許多客戶的供應商，有些則僅為您的組織在內部建構。這些應用程式會在許多不同的技術中寫入數十年，其中一些您必須詢問您的母親。有許多整合機制可以處理 - 檔案交換、共用資料庫、訊息中介軟體。每隔一段時間就會有人嘗試合理化所有這些通訊技術，但他們從未完全成功，留下更多複雜性在他們身後。

即使不同的應用程式存取相同的資料，它們之間仍有相當大的概念不協調，客戶對銷售組織的意義可能與對技術支援的意義截然不同。在不同的背景中，相同的實體名稱有不同的欄位，或更糟的是，欄位名稱相同但意義不同。

然後還有所謂的「商業邏輯」。當您撰寫作業系統時，您努力使整個系統保持邏輯性，並努力發現和實作簡化，以保持軟體直接且可靠。但商業規則會照原樣提供給您，如果您想變更它們，您需要舉行六十七次會議，並讓三位副總裁退休。它們通常是一組隨機的奇怪條件，它們以令人驚訝的方式進行互動。它們的瘋狂來自於一個好的理由，每一個都是業務員可以透過提供一些特殊的一次性條件來達成特定交易的案例。這樣做一千次，您就會擁有許多企業應用程式核心的複雜商業「非邏輯」。

企業應用程式可以很大或很小。通常討論的重點是大型、複雜的應用程式，但對於需要快速建構的小型應用程式來說，這也是一個挑戰。大型系統在出錯時會發出很大的噪音，但小型系統的累積效應可能會對企業的健康產生驚人的影響。

為事物想出名稱總是棘手的。您需要使用最少的字詞，並希望它們在讀者的腦海中觸發正確的聯想，這樣您就不必不斷提醒他們定義的意義。總的來說，我對我的選擇相當滿意，但自從我完成這本書以來，企業這個詞已經有了與我的用法不太相符的含義。

自從這本書出版以來出現的一個問題是，「企業」現在通常是指一家大型、歷史悠久的公司。人們想到的是奇異公司或西門子公司，而不是 Facebook、Etsy 或一家生產客製化 T 恤的百人公司。但根據我上述的定義，即使是小型新創公司也依賴我所謂的企業應用程式軟體。因此，即使 Ruby on Rails 社群最終將企業用作侮辱，我仍會將 Ruby on Rails 稱為建構企業應用程式的架構，而 BaseCamp 是企業應用程式的經典範例。（只是不要告訴 DHH 我這樣說，否則他會把我變成引擎蓋上的裝飾品。）

這些圍繞「企業」的含意讓我思考我們是否需要不同的術語。當我撰寫 P of EAA 時，我的工作標題是「資訊系統架構」，但我們覺得「資訊系統」本身就有它不受歡迎的、較舊技術的含意。我想我可以真的復古一點，使用「資料處理」，但整體而言，「企業應用程式」似乎還是比我想得出的任何其他術語都還要好。