.NET及.NET Core系統架構

.NET 官方架構指南

Microservices and Docker Containers

Web Applications with ASP.NET

官網地址：https://www.microsoft.com/net/learn/architecture

三層及多層架構 Multitier Architecture

ASP.NET N-Tier Architecture Schema

Visual Studio N-Tier Example

來源：https://dotnetdaily.net/featured/n-tier-architecture-asp-net

微軟官方N-Tier 介紹：https://docs.microsoft.com/zh-cn/visualstudio/data-tools/n-tier-data-applications-overview

三層架構wiki

https://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture

https://en.wikipedia.org/wiki/Multitier_architecture

洋蔥架構 Onion Architecture

四個洋蔥架構（Onion Architecture）的原則：

• 應用程式是圍繞獨立對象模型構建的
• 內層定義介面。外層實現介面
• 耦合方向朝向中心
• 所有應用程式的核心代碼可以與基礎架構分開編譯和運行

原文：http://jeffreypalermo.com/blog/onion-architecture-part-4-after-four-years/

洋蔥架構有時也被稱為埠和適配器（Ports and Adapters）架構，或者是六邊形（Hexagonal）架構。不過Wade認為，後者應該是洋蔥架構的一個超集。

核心（Core）層是與領域或技術無關的基礎構件塊，它包含了一些通用的構件塊，例如list、case類或Actor等等。核心層不包含任何技術層面的概念，例如REST或資料庫等等。 
領域（Domain）層是定義業務邏輯的地方，每個類的方法都是按照領域通用語言中的概念進行命名的。對領域層的控制是通過API層進行操作的，而所有的業務邏輯都歸屬於領域層。這種方式保證了應用程式的可移植性，在不丟失任何業務邏輯的情況下替換掉整個技術實現。 
API層是領域層的入口，它使用領域中的術語和對象。Wade提到：API層應該僅僅向外界暴露不可變的對象，以避免開發者通過暴露的對象獲得對底層領域的訪問，並任意修改領域行為。Wade通常會從API層開始編碼工作，每個方法就是一個骨架，並且對應一個高層次的功能性測試。隨後添加代碼邏輯以使該測試通過，以此驅動領域層的編碼實現。 
基礎架構（Infrastructure）層是最外部的一層，它包含了對接各種技術的適配器，例如資料庫、用戶界面以及外部服務。它能夠訪問所有處於內部的層次，但多數操作是通過API層進行的。但也有一種例外情況的存在 ，就是負責實現領域層中所定義的某些介面（譯註：例如各種Repository的介面）。 

洋蔥架構中的一個重要概念是依賴，外部的層能夠訪問內部的層，而內部的層則對外部的層一無所知。

http://www.infoq.com/cn/news/2014/11/ddd-onion-architecture

整潔架構 Clean Architecture

依賴規則（The Dependency Rule）

同心圓代表的是不同層級的軟體代碼。通常當你更深一步思考構造你的系統的時候，你的系統就會在更高的層級。最外層的圈代表的是機制級別的系統。最內層的代表的是策略級別的系統。

最重要的一條規則是依賴規則（The Dependency Rule）。這條規則說的是：代碼依賴只能使由外向內。換句話說，內層結構的代碼不能包含有任何外層結構的信息。尤其是一些外層結構的名稱不應該被內層結構的代碼提到，比如函數名，類名，變數名，或者其他的系統實體的名稱。

同樣的，外層的數據結構不應該被內層代碼使用，特別是那些由外部框架生成的數據結構。我們並不希望外部結構的任何東西會影響到內部結構。

實體層（Entities）

實體是用來封裝公司的業務規則的。一個實體可以是一個帶方法的對象，也可以是一些數據結構和函數。只要實體能被公司的不同業務邏輯部件使用，實體的具體表現形式是無所謂的。

或許你並不是想寫公司級的架構，而只是想寫一個簡單的應用，那麼這裡實體就是指的應用的業務邏輯對象。它們封裝了最通用的規則，並且當外部環境變化的時候，這些實體是最不需要被變化的。舉例來說，比如在增加翻頁需求或者是安全需求的時候，這些實體是最不應該被改變的。沒有任何具體的應用需要改變實體層。

用戶實例層（Use Cases）

這一層的軟體結構包含了具體的應用業務邏輯。它實現了所有的用戶實例。這些用戶的實例由流入實體的數據流和流出實體的數據流實現，這些用戶實例使得內層的實體能依靠實體內定義的業務邏輯規則來完成系統的用戶需求。

我們不希望用戶實例層的任何改變會影響到實體層。我們同樣也不希望用戶實例層會被外部的結構層，比如UI、資料庫或者任何公共的框架，的改變而影響。這層應該是獨立於這些概念的。

當然，必然發生的是應用的業務邏輯被修改會影響到用戶實例層的代碼和結構。如果用戶的需求改變了，這層的部分當然會被修改。

介面適配層（Interface Adapters）

這一層的軟體結構的目的就是進行數據的轉換，將便於用戶實例和實體層操作的數據結構變化成為最便於外部結構（比如資料庫或者Web）操作的數據結構。比如GUI的MVC結構，表現器、視圖器、控制器都是屬於這個結構的。這層很可能是通過控制器將數據結構傳給用戶實例層，並且返回數據給表現器，視圖器。

數據在這層會被轉換，將便於實體層和用戶實例層使用的數據轉化成為持久層能使用的數據，比如資料庫。這一層的代碼並不需要知道任何資料庫的信息。如果資料庫是SQL資料庫，那麼，所有的SQL語言應當在這層被限制使用，特別是在這一層中與資料庫有交互的代碼部分。

當一些外部的服務需要與用戶實例層和實體層進行交互的時候，這時候需要的數據轉換也理所當然地放在這一層了。

框架和驅動層（Frameworks and Drivers）

最外層是由框架和使用工具組成的。比如資料庫，Web框架等。通常你並不需要寫很多代碼就能達到與內層進行交互的行為。

這層表達的是所有的數據應該具體最終到達的地方。Web是數據的最終到達地，資料庫也是數據的最終到達地。我們把這些東西放在最外層，它們幾乎對整個系統的架構造不成什麼影響。

原文：https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

譯文：http://www.cnblogs.com/yjf512/archive/2012/09/10/2678313.html

DDD領域驅動分層架構 Domain-Driven Design

四層架構

1. User Interface為用戶界面層（或表示層），負責向用戶顯示信息和解釋用戶命令。這裡指的用戶可以是另一個電腦系統，不一定是使用用戶界面的人。
2. Application為應用層，定義軟體要完成的任務，並且指揮表達領域概念的對象來解決問題。這一層所負責的工作對業務來說意義重大，也是與其它系統的應用層進行交互的必要渠道。應用層要儘量簡單，不包含業務規則或者知識，而只為下一層中的領域對象協調任務，分配工作，使它們互相協作。它沒有反映業務情況的狀態，但是卻可以具有另外一種狀態，為用戶或程式顯示某個任務的進度。
3. Domain為領域層（或模型層），負責表達業務概念，業務狀態信息以及業務規則。儘管保存業務狀態的技術細節是由基礎設施層實現的，但是反映業務情況的狀態是由本層控制並且使用的。領域層是業務軟體的核心，領域模型位於這一層。
4. Infrastructure層為基礎實施層，向其他層提供通用的技術能力：為應用層傳遞消息，為領域層提供持久化機制，為用戶界面層繪製屏幕組件，等等。基礎設施層還能夠通過架構框架來支持四個層次間的交互模式。

傳統的四層架構都是限定型鬆散分層架構，即Infrastructure層的任意上層都可以訪問該層（“L”型），而其它層遵守嚴格分層架構