.net架構設計讀書筆記--第二章 設計體系結構

第五節 探索領域架構

1、領域驅動設計的價值與意義

最初在java中使用，.net要晚些才引入。領域驅動設計出現之初的爭議。一個嚮導，少走彎路

 

1. 咱們真的須要DDD嗎？

DDD並不適用於每一個軟件項目，由於他須要掌握一相技能，可有較高的啓動成本。也不會由於一個項目簡單而阻止你使用DDD，在是否DDD方面有兩誤區，你以爲使用他很cool，你以爲項目只有稍複雜的CRUD。使用DDD的真正價值在於理如什麼時候解決它併合理利用它

• 使用DDD分析

DDD 的分析部分包括兩個相關元素: 通用的語言和邊界上下文。

• 戰略模型設計 Strategic model design

能夠稱DDD爲面向領域模型的分層設計。模型能夠是對象模板，也能夠是或函數方法的集合。數據的持久性也依賴於模型，它多是ORM工具映射出來的一組對象集合，也多是由組件封裝的存儲過程調用得到。

 

2、通用語言

    軟件爲業務而誕生，可是軟件架構師不業務領域的專家，一樣，業務領域的專家也可能不懂得軟件設計。開發人員和領域專家對同同樣單詞可對被理解爲不一樣意義。

1. 通用語言結構

2. 如何定義通用語言

通用語言是項目的官語言，貫穿於整個項目，coding、testing、document，它應該通過領域專業承認審覈。可能表示爲一組excel說明的短語，也多是UML中的圖表

3. 保持語言和模型的同步

3、上下文邊界

上下文邊界是應用程序的一個區域，在這個區域裏它有本身的通用語言，而且有本身的架構。

1. 定義上下文的邊界

• 單一上下文邊界要包含全部實體

• 不一樣的上下文邊界共享核心實體

 

• 不一樣的上下文邊界對通用實體作不一樣的定義

 

 

2. 上下文關係映射

上下文的數據和邊界上下文的關係每每是反映現實企業的物理組織架構，如人力資源、 會計、 銷售、 庫存、 等。 

Anticorruption layer (ACL) 防禦層	一個擴展層用來隱藏上游上下文對下游上下文的影響
Conformist 被動服從	下游上下文無條件適應上流數據，不定下流是否須要數據
Customer/Supplier 生產者/消費者	上下游關係的兩個經典關係模式，上游是生產者，下游是消費都，共同協做，確保不用數據不會實下游接收。這點不一樣於上一條
Partnership	兩個獨立的上下文，不共享數據，均可以同時爲上游或下游上下文。
Shared kernel	共享核心數據

    

3. Common supporting architectures 經常使用架構

Multilayer architecture	Canonical segmentation based on presentation, business, and data layers  The architecture might come in slightly different favors, such as an additional appli- cation layer between the presentation and business layers and with the business layer transformed into a domain layer by the use of a DDD development style  Layered architecture is just another name for a multilayer architecture  We'll be using the term layered architecture instead of multilayer in the rest of this chapter and throughout the book
Multitier architecture	Segmentation that is in many ways similar to that of a multilayer architecture   except that now multiple tiers are involved instead of layers  (More on the possible downsides of a layer-to-tier mapping in a moment )
Client/server architecture	Classic two-layer (or two-tier) architecture that consists only of presentation plus data access
Domain Model	Layered architecture based on a presentation layer, an application layer, a domain layer, and an infrastructure layer, designed in accordance with the DDD develop-ment style  In particular, the model is expected to be a special type of object model
Command-Query Respon Segregation (CQRS)	Two-fold layered architecture with parallel sections for handling command and query sides  Each section can be architected independently, even with a separate supporting architecture, whether that is DDD or client/server
Event sourcing	Layered architecture that is almost always inspired by a CQRS design that focuses its logic on events rather than plain data. Events are treated as frst-class data, and any other queryable information is inferred from stored events
Monolithic architecture	The context is a standalone application or service that exposes an API to the rest of the world  Typical examples are autonomous web services (for example, Web API host) and Windows services  Yet another example is an application hosting a SignalR engine

4。 Layers 和 tiers 的區別

Layers 指邏輯層，tiers指代碼層面物理層。

 

4、分層架構

 

簡單三層架構數據模型受限於數據存儲，隨着項目複雜度增加，單一的數據模式不能知足多種意義上的概念視圖，因此面向領域設計應運而生。

1. Presentation layer

展示層的職責是提供用戶UI來完成交互任務。一般來講，用與展示給用戶的數據稱之爲View model，用戶完成輸入後將數據傳送到後臺，這類數據稱之爲input model，大多狀況上這兩類模式是一致的，能夠用一個模型來表示。

2. Application layer

包含了系統中的全部業務邏輯代碼，應用層的職責是向展示層提供數據，而且要能夠承載將來的需求變化。應用層是實現用例的地方。

3. Domain layer

領域層承載整個業務，並不針對某個用例，換句說領域層包含了全部在應用層上編輯實現的業務邏輯。領域層由域模板和和一系列服務組成。域模板的性質能夠是多樣的，一般狀況下是一組實體映射模型，固然也能夠包含函數。

4. Infrastructure layer

基礎設施層是一切具體技術的使用，包括數據持久性 (O/RM 像實體框架的框架)、 特定安全 API、 日誌記錄、 跟蹤，IOC容器，緩存等等。

 

 

第6章 表示層 presentation

 

1、用例體驗第一(User experience frst)

軟件開發的目的是讓客戶用他本身喜歡的方式有效的完成他本身的業務。任務軟件存在都要產生結果，不管是屏幕、文件、或數據庫更新。越瞭解預期的結果，能夠越有效的掌控你的開發計劃。

當預期的結果含有用戶界面或用戶交互，專一於用戶交互引入 基於任務設計

1. 基於任務設計(Task-based design)

要一次性完成複雜的系統設計很困難，直接從模型開始設計不切合實際，輕量化的方法是從任務執行開始，每一個任務的輸入、輸出開始分析。使用UML設計用例是很好的選擇。

• 爲每一個用戶界面提供一個model

    類沒有多餘的行爲，只是作數據數據傳輸所用（DTO），用於在不一樣分層之間傳遞數據。

2. 用戶體驗不是用戶界面（UX is not UI）

• UX 專家的責任

UX專家也可稱之爲UX架構師、UX設計，是一個分析與設計並俱的角色。UX專家的任務是分析用戶行爲，而後爲系統設計一個好的用戶操做體驗。UX設計的主要原則

  ■ Information architecture 信息體系架構

  ■ Interaction design  交互設計

  ■ Visual design 視覺設計

  ■ Usability reviews 可用性評估

• UX設計工具 Tools for UX experts

Axure	http://www.axure.com
Balsamiq	http://balsamiq.com
UXPin	http://uxpin.com
Wirify	http://www.wirify.com

2、真實應用場景

展示層主要包含兩個組件：用戶接口和展示層邏輯。用戶接口爲用戶提供一個系統使用工具。.net框架下展示層應用包括web和wpf,winform。web下主要爲asp.net站點。

1. Asp.Net網站

典型的asp.net網站中展示層補分爲瀏覽器端和web服務端。用戶接口使用html在瀏覽器上呈現給客戶，邏輯部分由IIS等服務端承載。asp.net mvc和webform對錶示層兩種不一樣方式的實現。

• Application Services

在asp.net應用程序中，應用層被設計爲controller, 在內部咱們也將application-layer稱之爲worker services，如今咱們趨向於將worker services稱之爲DDD中的application services.

如上圖解：決方案中的HomeController與HomeServices關聯。一個HomeServices實例經過IOC容器或人爲注入到HomeController中。

這個項目中中，application layer用解決方案的一個Services文件夾表示。能夠將Services移出到一個獨立的層，用宿主程序來承載，包裝公開爲終結點。（能使用web api的就不要使用wcf, 微軟在web api和signalR上投入不少，推薦使用）

Application service類的方法與用例一一對應，每一個方法都實現一個必要的流程，由input mode開始，返回view mode。大多狀況下controller的邏輯可簡單爲以下的Index方法。

public class HomeController 

{ 

    private readonly IHomeService _service; 

    public HomeController(IHomeService service) 

    { 

       _service = service; 

    } 

 

    public ActionResult Index() 

    { 

       var model = _service.FillHomePage( /* input model */ ); 

       return View(model); 

    } 

    ... 

}

Application Services有訪問全部底層應用的權限，能夠查詢、更新數據，若是有須要能夠擴展爲web services。若是有demain model, application services應該要有權限將這些實現轉爲view model的功能。