265
《Microsoft.NET企業級應用架構設計（第2版）》——導讀
前言
我們寫這本書的主要目的是為你帶來一個關於軟件架構的堅實、可重用以及易於訪問的知識庫。在過去，我們使用Microsoft Windows DNA、分布式COM、多層CRUD、SOA、DDD、CQRS和事件溯源等技術完成了很多項目。我們用過Microsoft Visual Basic 6、C#、C++、Java和JavaScript。我們目睹了技術解決方案不斷改變，對於這些方案的看法也進化了。
最終，我們和Fred Brooks得出的結論相同。我們不穿白袍，我們不是醫生，我們不寫處方。我們在這裏的目的是匯聚各方觀點，加入我們對這些觀點的見解和評論，如實地總結這些事實和看法。
當開發者和架構師被要求立刻采取正確的方案時，我們提供一個知識快照——現成的軟件架構師心得，可以用作進一步研究的起點，也可以用來形成你自己的判斷。如果軟件架構是一個定理，（我們希望）這本書將會提供一些必要的引理。
軟件架構有一些前置條件（設計原則）和一個後置條件（實現一個產生預期結果的係統）。本書的第1部分是“基礎”，為軟件架構打下基礎，關注架構師的角色、軟件項目的固有機製以及提升軟件品質方麵，如可測試性和可讀性。
第2部分是“設計架構”，關注構成典型企業係統的最上麵兩層：表現層和業務層。我們把標準的第3層放在後麵：數據訪問層。我們推行一個比較新的係統設計方案，叫作用戶體驗優先。它是一個基於任務的方法學，從達成共識的模型和屏幕引出命令和領域事件。就基於任務的設計理念而言，領域模型的角色不再是中心，數據訪問層也隻是基礎設施的一部分了，而且不一定基於標準的關係型表。第2部分最給力的一章是第5章“發現領域架構”，我們推薦所有人閱讀。簡而言之，這章的觀點是隻有深刻理解領域才能發現合適架構。更重要的是，結果架構不一定是適用於整個應用程序的單個頂層架構。當識別出子領域時，你可以把它們建模成子應用程序，給予每個最有效的架構。聽起來可能有點奇怪，但這就是領域驅動設計（DDD）的要旨。
第3部分是“支撐架構”，涵蓋3個可以用來構建各種子領域的支撐架構。每個架構都有兩章——介紹和實現。我們考慮的第一個支撐架構是領域模型。接著，我們會講命令/查詢責任分離（CQRS）和事件溯源。
最後，第4部分“基礎設施”，隻包含一章，它處理基礎設施和持久層。有趣的是，這章不僅僅講到SQL、Entity Framework和關係型數據庫，還著重講了多樣化和持久化、NoSQL數據存儲和用來隱藏存儲細節的服務。
那麼，這本書到底是關於什麼的？
這是關於在.NET平台上更好地滿足你的客戶需要知道和做到什麼的一本書。我們給出的模式、原則和技術一般來說都是有效的，並非針對複雜的行業係統。一個好的軟件架構可以幫助控製項目的複雜性。控製複雜性和支持可維護性是我們應對技術領域的墨菲定理的最好策略：“沒有什麼能按時、按預算構建出來。”為了做到這點，隻有一件事情是不允許失敗的：（深刻）理解業務領域。
目錄
第1部分 基礎
第1章 今天的架構師和架構
1.1 軟件架構到底是什麼
1.1.1 把架構原則應用到軟件中
1.1.2 確認需求
1.1.3 什麼是架構，什麼不是
1.1.4 架構流程
1.2 誰是架構師
1.2.1 架構師的職責
1.2.2 架構師的角色
1.2.3 關於架構師的常見誤解
1.3 總結
1.4 笑到最後
第2章 為成功而設計
2.1 “大泥球”
2.1.1 “大泥球”的成因
2.1.2 “大泥球”的征兆
2.1.3 使用指標檢測BBM
2.2 軟件項目的機製
2.2.1 組織文化
2.2.2 幫助團隊更好地寫代碼
2.3 走出混亂
2.3.1 有一種奇怪的東西叫作“遺留代碼”
2.3.2 在3招之內將殺（checkmate）
2.3.3 決定是否添加人手
2.4 總結
2.5 笑到最後
最後更新：2017-06-06 07:35:57