Api容器在應用架構演化中的用途

單層架構

在最開始編程的時候相信你們都寫過下面這種架構,界面代碼，業務代碼，數據庫鏈接所有在工程面完成。固然這種架構在處理很小的程序的時候依然有生命力

兩層架構

後來咱們發現數據訪問的代碼大量重複，應該進行抽象，因而單獨將數據訪問相關的代碼封裝出一個數據訪問層，就是用Sqlhelper將數據庫訪問的方法封裝，用DataTable返回到ui之中使用。

三層架構

隨着業務規模的增長，UI層代碼愈來愈多,而且有大量邏輯重複的代碼，因而將UI曾中業務邏輯代碼抽象出一層，放到BLL中，UI只處理一些界面展現，跳轉，參數校驗等相關內容，可是此時咱們用的數據結構大部分狀況下仍是放在一個集中的工程Data中。

單個領域分層

當業務複雜度繼續提升的時候，你會發現以下問題：

1. 服務之間有大量重複的代碼
2. 修改一處業務須要改動多個地方的代碼
3. 服務會引用服務
4. 服務之間關係很是混亂
5. 甚至會出現相互引用的狀況

在領域中運用以下戰術設計解決上述問題

1. 通常解決重複代碼的思路都是將代碼下沉(放到分層結構的更下面的層)，可是隨着複雜度的增長，一樣會出現重複的問題，在領域驅動設計中，是將業務邏輯放到實體中，而實體是用來承載數據，能夠說是最底層。這樣就解決了重複代碼的問題。
2. 將業務邏輯封裝到領域以後，邏輯集中後修改起來也比較方便
3. 由於業務邏輯都在領域層因此服務直接的依賴變成服務和領域層的依賴
4. 實體之間的邏輯是經過聚合根或者領域服務來組織。
5. 原來的BLL層變成Application層。基本上一個應用服務的接口對應一個業務用例。由應用服務來調用領域處理業務，同時處理業務以外的一些技術和交互邏輯：例如 持久化,上下文交互等等

多個領域分層

隨着對業務的理解，會造成一組一組這種概念(領域的劃分)。

單進程多領域六邊形架構

若是咱們引入領域驅動中六邊形架構以後(六邊形架構其實能夠認爲是領域分層的一種實現方式):

1. 此時將Application的契約和實現分離到不一樣的項目之中。
2. 對六邊形內部的訪問都必須經過契約來調用

Api容器的多進程改造

一個六邊形理解爲一個模塊

1. 進程間通訊使用Http
2. 將全部模塊的Contract組織到一塊兒(每一個Contract依舊是一個項目)
3. 將原來的契約，契約實現，領域，倉儲實現，放到容器之中
4. 調整工程間的依賴關係保證模塊和模塊，ui和模塊之間沒有相互應用
5. UI和其餘模塊，只需利用ioc將實現註冊到契約修改爲客戶端代理註冊到契約便可.

總結

恰如其分的架構中提到三種設計方式：

1. 演進的設計: 知足客戶現有需求，追求快速編碼快速實現。
2. 計劃的設計：考慮將來擴展，保證開發過程有條不紊
3. 最小化設計: 作適當設計，這是介於演進式和計劃式。

最近很流行微服務,都拿微服務和單體架構作對比,可是若是初期就設計一個微服務那麼架構和維護成本過高，不少產品初期團隊根本不具有這樣的資源，可是若是開始就設計一個單體架構可能又知足不了將來業務的發展.若是微服務架構是一個計劃式設計的話，那單體架構就是一個演進式架構。可是這種演進的成本很高，甚至面臨着重作的風險。

若是咱們引入六邊形架構這種最小化設計，再結合api容器就能夠幾乎0成本的將單體架構切換到微服務.

PS:每一個架構演化均可以說不少，網上已經有不少這種說明，這裏就沒有詳細的說明，有興趣的能夠留言討論.