軟體架構指南 - martinfowler

什麼是架構？
軟體世界的人們一直在爭論架構的定義。對於某些人來說，它類似於系統的基本組織，或者最高階別元件連線在一起的方式。我對此的想法是透過與拉爾夫·約翰遜（Ralph Johnson）進行電子郵件交流而形成的，他質疑這種措辭，認為沒有客觀的方法來定義什麼是基礎或高階別，更好的架構觀點是專家開發人員的共同理解擁有系統設計。
架構的第二種常見定義是，它是“需要在專案早期做出的設計決策”，但拉爾夫也抱怨這一點，並說這更像是你希望你能早日對一個專案做出的決定。
他的結論是“架構是重要的東西。無論那是什麼“。乍一看，這聽起來很陳舊，但我發現它帶來了很多豐富。這意味著在架構上思考軟體的核心是：判決什麼是重要的（即什麼是架構），然後花費精力來保持這些架構元素的良好狀態。要讓開發人員成為架構師，他們需要能夠識別哪些元素是重要的，識別哪些元素在不受控制時可能導致嚴重問題。

為什麼架構很重要？
架構對於軟體產品的客戶和使用者來說是一個棘手的主題 - 因為它不是他們立即感知的東西。但是，糟糕的架構是軟體增長的主要原因 - 軟體的元素阻礙了開發人員理解軟體的能力。包含大量內容的軟體更難以修改，導致功能更慢，更多缺陷。
這種情況與我們通常的經歷相反。我們習慣於“高品質”的東西，因為它的成本更高。對於軟體的某些方面，例如使用者體驗，這可能是真的。但是當涉及到架構和內部質量的其他方面時，這種關係就會逆轉。高內部質量可以更快地交付新功能，因為可以減少阻礙。
雖然我們可以在短期內犧牲質量以便更快地交付，但是在殘餘物的形成產生影響之前，人們會低估這種殘餘物導致整體交付速度變慢的速度。雖然這不是可以客觀衡量的事情，但經驗豐富的開發人員認為，對內部質量的關注會在數週而非數月內得到回報。

應用架構
軟體開發中的重要決策因我們正在考慮的環境規模而異。常見的規模是應用程式的規模，因此是“應用程式架構”。
定義應用程式體系結構的第一個問題是，沒有明確定義應用程式是什麼。我的觀點是 應用是一種社會建構：

• 開發人員將其視為一個單元的程式碼體
• 企業客戶將一組功能視為一個單元
• 一項倡議，那些有錢的人將其視為單一預算

應用邊界

微服務指南

無伺服器架構

Micro Frontends

GUI架構

表現領域資料分層

企業架構
雖然應用架構專注於某種形式的名義應用程式邊界內的體系結構，但企業架構看起來跨大型企業的體系結， 這樣的組織通常太大，無法將其所有軟體分組到任何型別的內聚組中，因此需要跨多個具有許多程式碼庫的團隊進行協調，這些程式碼庫彼此隔離開發，資金和使用者彼此獨立執行。
許多企業架構都是關於理解什麼是值得中央協調的成本，以及協調應該採取什麼形式。一個極端是中央架構組，必須批准企業中每個軟體系統的所有架構決策。這些群體減緩了決策制定，無法真正理解如此廣泛的系統組合中的問題，從而導致決策失敗。但另一個極端是根本沒有協調，導致團隊重複工作，不能讓不同的系統互操作，以及團隊之間缺乏技能開發和交叉學習。
像大多數具有敏捷思維方式的人一樣，我更傾向於在分權方面犯錯，因此會更接近混亂的岩石而不是窒息控制。但是，在渠道的這一方面仍然意味著我們必須避開岩石，並以最小化所涉及的實際成本的方式最大化地方決策。

參考：

企業架構師加入團隊

企業架構師在精益企業中的角色

產品超過專案

建築師電梯 - 訪問較高樓層

​​​​​​​