我們遇到的任何軟件系統(tǒng)很可能都過于復雜，一次無法完全理解 — 人類的思維無法理解大量實體及其關系。我們傾向于通過建立抽象來簡化現(xiàn)實：一旦我們將許多閃亮的金屬、玻璃和橡膠定義為“汽車”，我們就可以談論“高速公路”、“停車場”和“乘客” — 我們生活在我們創(chuàng)造的抽象世界中。同樣，我們編寫的軟件由服務、進程、文件、類、過程等組成 — 這些模塊隱藏了我們無法抗拒的一堆位和片段。讓我們思考一下。

概念與復雜性

任何系統(tǒng)都包括 概念 — 以其他概念為基礎定義的概念。例如，如果你正在實現(xiàn)一個電話簿，你會處理 名 和 姓、號碼、排序 和 搜索，這些概念是任何與電話簿相關的開發(fā)任務中必須牢記的 — 只因為電話簿的需求是用這些概念及其關系描述的。

在代碼中，高級概念被體現(xiàn)為服務、模塊或目錄，而較低級的概念則對應于類、API 方法或源文件。

概念很重要，因為它們的數(shù)量（或相應類和方法的數(shù)量）定義了系統(tǒng)的 復雜性 — 開發(fā)人員面對的認知負荷。如果程序員詳細了解他們正在處理的組件的行為，他們往往會變得極其高效，并且通常能夠為看似復雜的任務找到簡單的解決方案。否則，開發(fā)速度會很慢，并且需要進行大量測試，因為人們不確定他們的更改會如何影響系統(tǒng)的行為。

圖1：復雜性與實體數(shù)量相關

模塊、封裝和有界上下文

讓我們回到我們的例子。當你實現(xiàn)電話簿時，你會發(fā)現(xiàn)排序和搜索比你最初想象的要復雜得多。一旦你準備進入國際市場，你就會陷入深深的困境。一些電話服務提供商發(fā)送7位數(shù)字，其他人使用10位數(shù)字，還有些人使用13位數(shù)字（第一個字符為“+”或“0”）。德語有“?”，它與“ss”相同，而日語同時使用兩種字母表。一旦你開始閱讀標準，實現(xiàn)所有奇怪的行為并回應用戶投訴，你會感到你的電話簿實現(xiàn)淹沒在充滿特殊情況的外語字母表的無關邏輯中。你需要 封裝。

引入 模塊。模塊封裝了幾個概念，有效地將它們隱藏在外部用戶之外，并暴露了其內容的簡化視圖。引入模塊將復雜的系統(tǒng)分成了幾個通常更簡單的部分。

圖2：將系統(tǒng)劃分為模塊，突出顯示有界上下文

該圖有幾個值得注意的地方：

• 模塊為其 公共API 創(chuàng)建了新的概念。
• API 入口點增加了 擁有者模塊 和其客戶的復雜性。
• 系統(tǒng)中的概念總數(shù)已增加（從18個到22個），但系統(tǒng)中最高復雜度已下降（從18到15）。

在這里，我們看到引入模塊如何將分而治之的方法應用于減少在系統(tǒng)的任何部分上工作時的認知負荷，以較小的總工作量為代價。

在我們的電話簿示例中，與地區(qū)相關的字符串比較和聯(lián)系人姓名的字母排序的特殊性（包括大小寫敏感性）應該更好地保留在一個簡單的字符串比較接口之后，以解除電話簿引擎程序員對支持外語的復雜性的負擔。

模塊代表 有界上下文 [DDD] — 系統(tǒng)知識的領域，這些領域操作不同的術語集。對于電話簿來說，整理 和 大小寫敏感性 對于電話簿引擎并不重要 — 它們只在語言支持的上下文中定義。另一方面，通過號碼匹配聯(lián)系人 在語言支持模塊中并未定義 — 該術語僅存在于電話簿引擎中。程序員所面臨的是當前有界上下文的復雜性。

除了將問題分解為較簡單的子問題外，模塊還帶來了一些額外的好處：

• 代碼重用。一個良好編寫的模塊可以在多個項目中使用。
• 勞動分工。一旦系統(tǒng)被拆分為模塊，并且每個模塊都被分配給一個程序員，開發(fā)就會被高效地并行化。
• 高級概念。有些情況允許將原始問題的幾個概念合并為更高級的聚合，進一步降低復雜性：

圖3：合并了綠色模塊的兩個API概念

例如，電話簿的原始定義包含 名 和 姓。一旦我們將語言支持分離到一個專用模塊中，我們可能會發(fā)現(xiàn)各種地區(qū)在表示聯(lián)系人時有所不同：一些（美國）使用“名 + 姓”，而其他一些（日本）則需要“姓 + 名”。如果我們想要擺脫這個細節(jié)，我們應該使用一個新的 全名 概念，它以特定于區(qū)域的方式連接名和姓。這樣的改變實際上簡化了電話簿的某些表示邏輯和代碼，因為它用一個概念替換了兩個概念。

耦合度和內聚性

為了有效使用模塊，我們需要學習一些新的概念：

• 耦合度 是模塊之間連接數(shù)量（密度）的度量，相對于模塊的大小。
• 內聚性 是模塊內連接數(shù)量（密度）的度量，相對于模塊的大小。

經(jīng)驗法則是要追求 低耦合和高內聚，這意味著每個模塊應該封裝一組相關（密切交互）的概念。這就是我們在圖2和圖3中將系統(tǒng)劃分為的方式。現(xiàn)在讓我們看看如果我們違反規(guī)則會發(fā)生什么：

圖4：上部模塊耦合度高

拆分一個內聚模塊（一組相互交互的概念），會產(chǎn)生兩個強耦合的模塊。這正是我們想要的，只是每個新模塊幾乎與原始模塊一樣復雜。也就是說，我們現(xiàn)在面臨兩個艱巨的任務，而不是一個。此外，系統(tǒng)的性能可能很差，因為模塊之間的通信很少是最佳的，而我們卻有太多這樣的通信。

圖5：下部模塊內聚性低

如果我們將幾個概念集聚在同一個模塊中會發(fā)生什么？對于小模塊來說，不會發(fā)生什么太糟糕的事 — 模塊的復雜性高于其各個部分，但低于它們的總和。實際上，多個無關的函數(shù)通常被收集到一個‘utils’或‘tools’文件或目錄中，以減輕 操作復雜性。

開發(fā)與操作復雜性

我們上面討論的是 結構性 或 開發(fā)復雜性 —— 有界上下文內部的概念和規(guī)則的數(shù)量。然而，我們還需要理解系統(tǒng)作為一個整體的操作和組件，從而導致 操作 或 集成復雜性：

• 這個新需求是否適合現(xiàn)有模塊，還是需要一個專用模塊？
• 我們使用了哪些存在已知安全漏洞的庫？
• 有沒有辦法減少我們的云服務成本？
• 1% 的請求超時了。你能調查一下嗎？
• 我的團隊需要實現(xiàn)這個和那個。我們有適合重用的東西嗎？
• 那個全局變量到底是干什么的？
• 我們真的需要將這段代碼投入生產(chǎn)嗎？
• 我需要稍微改變一下那個共享組件的行為。有什么意見嗎？

當部署了數(shù)百或數(shù)千個模塊時，沒有人知道答案。這類似于需要在 Linux 下執(zhí)行某些操作的情況：已預安裝了數(shù)百個工具，數(shù)千個其他工具則作為軟件包可用，但唯一的前進方式是首先在搜索引擎中搜索您的需求，然后嘗試搜索結果中的兩三種方法，看哪種適合您的設置。不幸的是，谷歌并不索引您公司的代碼。

模塊的組合

一個模塊不僅可以封裝單個概念，還可以封裝其他模塊。這并不奇怪，因為 OOP 類是一種模塊 — 它具有公共方法和私有成員。將一個模塊隱藏在另一個模塊中會將其從全局范圍中刪除，減少了系統(tǒng)的操作復雜性 — 現(xiàn)在不再是系統(tǒng)的架構師，而是外部模塊的維護者必須記住內部模塊。一方面，在組織和代碼中建立了可管理的層次結構。另一方面，代碼重用和許多優(yōu)化幾乎不可能實現(xiàn)，因為內部模塊在整個組織中幾乎不為人知：

圖6：模塊的組合阻止了重用

如果我們的內部模塊的功能被我們的客戶需要，我們有兩個不好的選擇：

轉發(fā)和重復

圖7：轉發(fā)內部模塊的API

我們可以將我們封裝的模塊的API添加到我們的公共API中，并將其調用轉發(fā)到內部模塊。然而，這會增加我們模塊的復雜性，并降低我們模塊的內聚性 — 現(xiàn)在我們模塊的每個客戶都暴露于我們封裝的模塊的方法的細節(jié)中，即使他們并不打算使用它。

圖8：重復內部模塊

另一個不好的選擇是讓需要我們封裝的模塊的客戶復制它并擁有副本作為自己的子模塊。這使我們擺脫了任何共同的責任，讓我們可以任意修改和誤用我們的內部，并違反了常識的一對 規(guī)則。

這兩種方法，即將所有模塊保留在全局范圍內和通過組合封裝實用模塊，都在歷史上找到了它們的位置[FSA]。面向服務的架構 基于重用的想法，但卻成了其 企業(yè)服務總線 的復雜性的犧牲品，該總線必須考慮系統(tǒng)中的所有交互（API 方法）。作為反應，微服務 方法把潮流轉向了相反的方向：其支持者不允許在服務之間共享任何資源或代碼，以確保它們的解耦。