《企業應用架構模式》 - 書摘精要

(譯者序)

“每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重複勞動。” ———— Christopher Alexander

招式套路可以千變萬化，紮實深厚的“內功”卻是始終如一；

(前言)

關於軟件架構的通用性的書籍，我推薦[POSA] —— “面向模式的軟件體系結構”；

迭代開發的核心在於只要軟件對用戶有用，就應當交付，即使這個軟件當時並沒有完成；

(引言)

大多數重要的企業應用都是按照某種形式的層次分層設計的；

企業應用：

- 企業應用一般都涉及持久化數據；
- 企業應用一般都涉及大量數據；
- 企業應用一般都涉及很多人同時訪問數據；
- 企業應用一般都涉及大量操作數據的用戶界面屏幕；
- 企業應用很少獨立存在，通常需要與散佈在企業周圍的其他企業應用集成；

企業應用是多種多樣的，不同的問題將導致不同的處理方法；

當構建企業應用系統時，關注硬件的可伸縮性往往比關注容量或效率更重要；

總的來說，購買新硬件還是比修改舊軟件來得便宜；

模式的關鍵點是它們源於實踐；

使用模式的關鍵之一是不能盲目使用；

每個模式相對獨立，但又不彼此孤立。有時候它們相互影響，如影隨形；

模式爲設計提供了一套詞彙，這也是爲什麼模式的名字這麼重要的原因；

(P12)

在分解複雜的軟件系統時，軟件設計者用得最多的技術之一就是分層；

當用分層的觀點來考慮系統時，可以將各個子系統想象成按照“多層蛋糕”的形式來組織，每一層都依託在其下層之上。在這種組織方式下，上層使用了下層定義的各種服務，而下層對上層一無所知。另外，每一層對自己的上層隱藏其下層的細節；

當然，並非所有的分層架構都這麼隔絕，但絕大多數是不透明的，或至少是幾乎不透明的；

(P15)

根據不同的問題，選擇一種適合的分離方式，但是切記一定要進行某種形式的分離 —— 至少在子程序級別；

(P16)

只要有可能就用 Web 表現方式，只有在必需的情況下才使用胖客戶方式；

(P19)

用“領域模型”而不是“事務腳本”正是面向對象的程序員所極力鼓吹的“理論體系轉換”的精髓；

(P20)

“領域模型”的價值在於你一旦掌握了它，就可運用許多現成的技術來較好地組織日趨複雜的領域邏輯；

(P21)

一旦習慣了“領域模型”，一般就可以在將來很好地運用它，從而受益終生；

在許多方面，“表模塊”是“事務腳本”和“領域模型”的一箇中間地帶；

(P22)

開發小組的經驗越豐富，我越傾向於使用“領域模型”；

(P23)

“事務腳本”、“領域模型”和“表模塊”這三種模式並不互相排斥。事實上，使用“事務腳本”來處理一部分領域邏輯，同時使用“表模塊”或“領域模型”來處理剩下的部分，這也是很常見的；

處理領域邏輯的常見方法是將領域層再細分成兩層。“服務層”獨立出來，置於底層的“領域模型”或“表模塊”之上。表現邏輯與領域層的交互完全通過服務層，就好像應用程序的 API 一樣；

如果設立了服務層，在其中置入行爲的多少是一個至關重要的決定：

- 最小化情況下，“服務層”只是一個外觀，所有實際的行爲都在下層的對象中，“服務層”所做的只是將上層調用傳遞到更低層。在這種情況下，“服務層”提供一個更易於使用的 API ，因爲它的方法通常根據用例來組織。此時，它也提供一個很方便的切入點，用來增加事務封裝和安全檢查等功能；

- 另一個極端則是將大多數業務邏輯都以“事務腳本”的形式置於“服務層”中。下層的領域對象變得極爲簡單。如果下層是“領域模型”，則其中的對象與數據庫一一對應，因而此時你就可以使用諸如“活動記錄”等較簡單的數據源層；

(P26)

清晰的 SQL 和領域邏輯分離是相當有益的；

(P27)

如果領域邏輯非常簡單並且類和表十分一致，使用“活動記錄”就足夠了；

如果領域邏輯比較複雜，“數據映射器”纔是需要的；

(P38)

儘量使用已預先編譯好的靜態 SQL ，而不是每次都編譯動態 SQL ；

(P62)

本地接口最好是細粒度接口。細粒度接口非常好，因爲它符合一般的面向對象原則，即儘量細分對象，使我們可以以不同方式組合和覆蓋這些對象以便在將來對設計進行擴展；

(P63)

只有在無法使用系統自己的遠程調用機制時，才使用基於 XML 的 Web Service ；

(P77)

“事務腳本”勝在簡單，對於只有少量邏輯的應用程序來說，使用這一模式非常自然，無論在性能上還是理解上都不會帶來太大的開銷；

(P81)

“領域模型”與系統中其它層之間的耦合程度應達到最小；

(P83)

要熟悉“領域模型”需要實踐和訓練，但是一旦掌握了它，我發現除了解決最簡單的問題外，很少會有人再使用“事務腳本”；

(P86)

“策略類”的巨大價值在於提供了一些良好封裝的插入點，來進行應用程序擴展；

(P87)

在面向對象技術中，通過從一個對象到另一個對象的連續傳遞可以把行爲傳給最有資格處理的對象，它同時也消除了許多條件判斷行爲；

相似的條件判斷語句可以提取到對象結構本身之中；

(P88)

面向對象的關鍵思想之一是將數據與對該數據操作的行爲綁定在一起；

(P94)

“服務層”定義了應用的邊界和從接口客戶層角度所能看到的可用操作集。它封裝了應用的業務邏輯、事務控制及其操作實現中的響應協調；

“服務層”類的接口是粗粒度的，就接口粒度而言，“服務層”類很適合於遠程調用；

(P96)

“服務層”的設計思想來自於應用邊界模式；

“服務層”的優點在於它定義了一個公共的應用操作集合，這一集合可被各種客戶使用，而且服務層在每個操作中都會協調應用的響應；

(P99)

“服務層”這一設計模式爲封裝應用的業務邏輯、實現和支持不同的客戶以一致的方式調用這些邏輯奠定了基礎；

(P101)

“表數據入口”接口很簡單，一般包括幾個從數據庫中獲取數據的查找方法以及更新、插入和刪除方法；

(P102)

“表數據入口”和“領域模型”很少一起使用，因爲“數據映射器”更好地分離了“領域模型”和數據庫；

“表數據入口”可以同“表模塊”一起很好地使用；它產生一個記錄集數據結構由“表模塊”處理；

(P103)

在 .Net 環境下，當操作大量信息但又不想一次把全部信息都調入內存時，數據閱讀器是合適的選擇；

(P107)

通常很難說清“行數據入口”和“活動記錄”之間的區別，這個問題的關鍵要看是否存在任何領域邏輯。如果存在，則是“活動記錄”。“行數據入口”僅包含數據庫邏輯而沒有領域邏輯；

(P275)

進程間調用的開銷比進程內調用的開銷更大 —— 即使兩個進程都在同一臺機器上；

(P340)

.Net 對值對象有良好的支持機制，在 C# 中通過聲明一個對象爲結構而不是類就將它標記爲值對象；

(P352)

如果依賴於完全不受自己控制的外部資源，通常會使軟件項目受挫；