《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.2 确認需求

1.1.3 什麼是架構，什麼不是

1.1.4 架構流程

<a href="https://yq.aliyun.com/articles/92710">1.2 誰是架構師</a>

1.2.1 架構師的職責

1.2.2 架構師的角色

1.2.3 關于架構師的常見誤解

<a href="https://yq.aliyun.com/articles/92714">1.3 總結</a>

<a href="https://yq.aliyun.com/articles/92716">1.4 笑到最後</a>

**[第2章 為成功而設計

2.1.1 “大泥球”的成因

2.1.2 “大泥球”的征兆

2.1.3 使用名額檢測bbm

<a href="https://yq.aliyun.com/articles/92736">2.2 軟體項目的機制</a>

2.2.1 組織文化

2.2.2 幫助團隊更好地寫代碼

<a href="https://yq.aliyun.com/articles/92743">2.3 走出混亂</a>

2.3.1 有一種奇怪的東西叫作“遺留代碼”

2.3.2 在3招之内将殺（checkmate）

2.3.3 決定是否添加人手

<a href="https://yq.aliyun.com/articles/92745">2.4 總結</a>

<a href="https://yq.aliyun.com/articles/92748">2.5 笑到最後</a>