Martin Fowler 的企業級軟體架構模式-推薦序-Joey Chen (91)

PoEAA序言三部曲：因為實體書局縮減，而且習慣於網路購物，但網路上針對「Martin Fowler的企業級軟體架構模式」一書的文案介紹譯者覺得過於制式，經過編輯同意，提供書中的「推薦序」「審校序」「譯者序」三篇序言，以提供給讀者在購買前能有多一些資訊。

1. Martin Fowler 的企業級軟體架構模式-推薦序-Joey Chen (91)
2. Martin Fowler 的企業級軟體架構模式-審校序-Jeffray Huang
3. Martin Fowler 的企業級軟體架構模式-譯者序-Bruce Chen,Poy Chang

Tenlong購買：https://www.tenlong.com.tw/products/9786263330504

在產品開發過程中，是否曾遇過這樣的疑問

1. 這功能的實作該放在哪邊合適，前端？後端？還是資料庫？
2. 我們架構設計要選擇單體？SOA？微服務？前後端分離？
3. 當系統有多個服務、子系統，線上同時多人讀取、多人在修改同一份資料時，該怎麼做好資料在讀取時的一致性，以及更新時不會遺失異動的資料，怎麼避免大家需要等待的時間太長？

正是因為不管程式怎麼寫，功能其實都會動，但錯誤或不合適的架構設計，可能帶來巨大的損失。要嘛是產品還在試探市場階段，就因為錯誤的架構決策導致開發速度延宕、提早把錢燒光，要嘛是產品不小心在市場上獲得青睞，有越來越大的商業價值及大量增加的使用者。伴隨著功能越來越多、越來越複雜，而你的開發團隊卻只想著「能不能重寫一個系統」時，這就是個巨大災難。

所以每個設計決策都是一種評估，一種取捨，你得找到最適合現況各種限制的設計方案，但如果你的口袋裡面永遠都只有鎚子，那當你看到的不論是螺絲、卡榫，你也都只能當釘子敲。

關於架構設計：剛好才是最好

在架構方案選擇時，千萬別輕視「殺雞用牛刀」所帶來的開發、維護、維運、複雜度等問題，例如在該用單體的部份採用微服務，在只需要用Transaction Script的模式時使用Domain Model，應該要避免只是一味追求著潮流而忽略了在達到目標的過程中所須考量的限制。要端出好的架構設計方案，你得不斷充實自己，只有當口袋中有很多選擇時，才能在最合適的場景選擇最剛好的方式。對我來說，一個合格的架構師在考量架構設計決策時，應該包含金錢、時間、團隊技能限制、領域特性、方案延展性，甚至工具服務生態系、人才招募難易度，都需要被評估在內。

或許你眼前尚未需要設計一個全新的系統架構，這本書仍能幫助我們奠定許多架構設計必要的知識與基礎。例如：

1. 知道目前產品正在用的架構設計模式叫什麼名字，以幫助團隊溝通與學習瞭解。
2. 瞭解我們為什麼選擇這樣的架構模式，是基於如何的context，在哪些方案中選擇了這樣的方式。當時的架構設計是否還適用目前的context？
3. 還有哪些企業架構的模式，適合應用在怎樣的情境與限制，來達到怎樣的目的與效益。

這本書適合我嗎？

可能有些讀者會有這樣的疑問：

1. 這本老書的內容，還適用於現代的軟體產品嗎？
2. 我的公司、產品或是台灣，用不到那麼多不一樣、複雜的架構設計方案？
3. 我只是個Programmer，架構設計我無權介入、干涉或調整？

我個人的建議是，讀書是突破自我界限最划算的投資，透過這種在架構設計領域上的經典書，才能鑑古知今，才能站在巨人的肩膀上去瞭解來龍去脈。雖然技術不停的演進，但產品、需求跟架構仍有一些共同的痛點，如何在不同的架構模式中異中求同，先找到相同的部份，再瞭解不同作法是基於怎樣的時機、怎樣的context來用不同角度解決哪些特定的痛點。當你多瞭解一點，你就不會只能單方向的承受目前架構帶給你的痛苦，而是還有機會貢獻一己之力來改善，至少讓未來的自己不要再那麼痛苦。

就像Steve Jobs曾經說過的，「你現在學習的每個片段知識你得相信在未來適當的時機，他們就會串連起來發揮作用。」當你學會的片段越多，連起來的機率就越大。所以學習曲線一直以來都不是線性的，而是當你學得越多，接著你就學得越輕鬆。只是大部分的人都跨不過去一開始的那一道障礙。如果這個東西這麼難懂，那麼對很多人來說，是一樣難懂的。而你已經花了一段時間跟心力，去發現「它很難懂」。而別人連這段時間都還沒有投入，當未來在實務上真的發生這樣的問題或需求時，你需要暖機的時間就比別人少一點。因此，當你是在問題發生之前學習，而其他人在發生問題時才學習，對你來說這根本不是問題，對他們來說卻是未曾碰過的問題，自然而然對旁人或你的老闆來說，就會覺得你是有天份、有潛力的員工。

內容簡介

這本書的脈絡安排也是我很喜歡的，一開始先介紹了幾個常聽到的、顆粒度比較大的詞彙，先從幾個大的Layer 介紹，例如邏輯層與Domain、資料存取層/關聯式資料庫/ORM、UI呈現層/View，就像對照到常見的軟體架構圖，針對每一層介紹有哪些常見的模式用來解決哪些特定的問題。

接著介紹系統架構中常需要面對的問題，包含了離線與並行處理、交易管控、Session的狀態設計，現代的軟體架構有許多分散式架構、分散式交易、透過Message Queue或Pub/Sub來非同步進行溝通，同時常見的高並行（High Concurrency）交易系統，或是多人共筆文書檔案的資料讀取與寫入鎖定，採取怎樣的策略會帶來怎樣的好處與限制，瞭解這一些設計背後的來龍去脈，才更能看懂每一種技術方案的價值、優勢、影響範圍與對應付出的代價。

最後則針對一些軟體系統架構設計中的「基礎」介紹一些常用到的模式，這些都是一些小小投入、大大收益的小技巧，也幾乎在大部分系統中都適用的基本設計，例如與外部相依的部份建議透過Gateway或Adapter來隔開，避免整個系統都直接相依外部資源，除了不具備可測試性外，更嚴重的是，當不可控的外部界面或資源異動，例如收費、安全性、版本不相容、替換合作廠商等，導致整體系統都須跟著調整，所需的成本、時間與風險極高。就像近期Log4j安全性問題，就考驗著每個系統在架構設計時，是否考量到這種情況發生時的維護成本。

最近聽到一個好友在面試時，應徵者提到Structs（結構）的使用是惡魔，或許他也適合來看看什麼時候該用 Value Object的模式，哪些情況下希望把一些物件或資源設計成不可變性，避免在預料以外的情況因為By Reference被修改，導致遺失更新的資料與狀態。

也很常看到在遺留系統中，到處充斥著回傳null來代表某些異常或特殊案例的情況，導致每個呼叫端加上整個 call stack都要穿插著一堆判斷null來決定流程是正常還是異常的處理。有這類的痛點，我也推薦看一下第18章的Special Case，讀通了就知道原來Null Object模式是這一類Special Case的其中一個典型例子。

最後再舉個Service Stub的模式，用在單元測試程式中，就是隔離依賴、模擬依賴的作法。而放到實際的架構與產品程式碼中，就可以透過判斷環境再搭配Plugin模式，來動態決定在不同環境中組合出對應的程式執行流程。尤其是在非正式的測試環境，針對依賴許多其他服務的端到端自動化測試，例如微服務搭配容器化技術，你都該具備能力以避免因為系統依賴某個服務而影響了產品團隊的開發與測試流暢性。

看完這本書，建議再回頭去看比較新的Clean Architecture與DDD的書，就不難理解裡面的許多設計與基本原則其來有自。

萬變不離其宗

最後我想呼應與強調一下書裡第8章其中一小段來自作者的友善提醒：

好的決策不會永遠一成不變。架構重構是相當困難的，人們亦經常忽視其背後的代價，但這並非是不可能的。在這裡，我能提供最佳建議是，即使你不喜歡極限程式設計的全部內容，也應該認真考慮三種技術實踐：「持續整合」、「測試驅動開發」和「重構」。這些技術雖然不是銀子彈，但是它們能在你需要幫助的時候，更容易異動你的系統。除非你比我迄今為止見過的任何人都還要幸運或精通開發的藝術。

在軟體的世界，唯一不變的，就是一直在變。所以再高超的架構設計圖，也得有足夠扎實的實踐能力才能穩妥的達成目標。技術人員應該善用技術來滿足商業目標，創造商業價值，同時也該避免自己成為一個只會出張嘴的「架構太空人」。

你要期許自己慢慢成為一個既能捲起袖子、弄髒雙手做實事的工程師，也要成為熟悉產品領域、洞悉市場趨勢、結合技術優勢來產生綜效的企業人才，並讓自己所提出系統架構設計方案能顧及目標、限制、資源、領域特性、時程、技術生態系、未來延展性以及招募人才難易度等面向。

這三者兼具，才能稱得上是某個產品領域稱職的Enterprise Architect，期許這本經典好書能在你的這段養成旅程中，扮演著營養劑的角色，讓你不只會做，還能說出其所以然。讓你永遠不會只有一個選項，而是能說出為什麼從諸多方案中選擇了這種作法。讓你能奠定好不變的基礎，以因應持續在改變的時代潮流，讓你能用最短時間瞭解新的架構設計背後的本質。

Odd-e Taiwan敏捷技術教練
陳仕傑 (91)
2022/3/20