Net應用架構設計

N-Tier

是從架構更大的次元上劃分，每一個次元都是一個Tier（在微軟的ESP2.0裡翻譯為”級”），比如電商架構劃分如下：

1. UI
2. 服務接口
3. 消息、緩存中間件
4. 資料庫
5. ......

Tier與Tier之間通過Tcp/Http通訊，并且每一級都可以獨立部署。

N-Layer

相對Tier，Layer是更細粒度的劃分，比如服務接口Tier就可以劃分為：表示層、業務邏輯層和資料通路層三個Layer。每一個Layer是沒有必要獨立部署的，否則隻會更影響性能。

總結

Tier一般指實體上的分層，Layer是邏輯上的分層。

分層重要思想

職責分離和關注點分離。

架構拆分的常用方法

1. 化整為零
2. 動靜分離
3. 按功能拆分

Anemic Domain Model

貧血型領域模型模式，和Domain Model很像，主要差別如下：

1. Domain Model的領域類中包含了自身的業務邏輯和資料，以及對象之間的關系
2. 貧血型的領域類将與自身相關的業務處理邏輯全部轉移到了模型之外--有專門的業務規則類，這使得領域類成為了一個簡單的資料對象。

政策模式

把不同的算法和行文分别封裝成獨立的對象（類），實作統一的政策接口；具體業務依賴于政策接口，進而可以靈活實作算法、行為的切換。主要解決在有多種算法相似的情況下，使用 if...else 所帶來的複雜和難以維護問題。

裝飾者模式

核心思想優先采用組合而不是繼承。

模闆方法

最直接的了解就是“模闆”：包括變化和不變化的兩個部分，将變化的部分交給子類實作。一個重要的點就是“鈎子”函數，一種被聲明在抽象類中的方法（空的和預設的實作），可以讓子類自己決定對算法的不同點進行挂鈎。

政策模式是除了繼承之外的一種彈性方案。如果采用繼承來定義一個類的行為，我們将會被這個行為困住，甚至修改起來很困難。有了政策模式，就可以通過組合不同的政策對象來改變行為。

服務定義粒度：

1. 不要使用泛泛的UpdateCustomerDetails來定義操作，而要用ChangeCustomerAddress、RecordCustomerMarriage之類的有業務意義的名稱來定義操作。操作簡單、易于了解，進而提高了易用性。
2. 如果服務使用的範圍有限，如僅僅在企業内部應用內建，則可以選擇相對較細粒度的服務接口，為服務請求者提供更多靈活性，如果服務使用的範圍擴大，服務的大小也應随之擴大，如企業外部內建
3. 多參數時采用結構化，個人認為超過3個時最好用結構化入參。操作靈活，不幹擾現有使用者的情況下提供新版本。

預約保留模式

1. 發送一個請求給伺服器，從服務端的響應中擷取一個預約保留的唯一編号（有一定期限，為了避免資源耗費及一些安全性問題）
2. 用戶端餘下的請求中都會帶上這個編号，以便伺服器把這些請求當成一個事務來處理

等幂模式

1. 每一次用戶端請求都被賦予了一個唯一的請求辨別（生成規則可能是通過這個請求的一些參數做一些算法來生成）
2. 服務端在一個存儲區域檢查這個唯一的辨別所代表的請求是否已經被處理過了，是否有對應的響應資訊，如果有就從響應儲存設備（如資料庫、緩存）中傳回響應資訊，如果沒有再次處理這個請求。