在最開始編程的時候相信你們都寫過下面這種架構,界面代碼,業務代碼,數據庫鏈接所有在工程面完成。固然這種架構在處理很小的程序的時候依然有生命力數據庫
後來咱們發現數據訪問的代碼大量重複,應該進行抽象,因而單獨將數據訪問相關的代碼封裝出一個數據訪問層,就是用Sqlhelper將數據庫訪問的方法封裝,用DataTable返回到ui之中使用。編程
隨着業務規模的增長,UI層代碼愈來愈多,而且有大量邏輯重複的代碼,因而將UI曾中業務邏輯代碼抽象出一層,放到BLL中,UI只處理一些界面展現,跳轉,參數校驗等相關內容,可是此時咱們用的數據結構大部分狀況下仍是放在一個集中的工程Data中。api
當業務複雜度繼續提升的時候,你會發現以下問題:數據結構
在領域中運用以下戰術設計解決上述問題架構
隨着對業務的理解,會造成一組一組這種概念(領域的劃分)。微服務
若是咱們引入領域驅動中六邊形架構以後(六邊形架構其實能夠認爲是領域分層的一種實現方式):ui
一個六邊形理解爲一個模塊編碼
恰如其分的架構中提到三種設計方式:設計
最近很流行微服務,都拿微服務和單體架構作對比,可是若是初期就設計一個微服務那麼架構和維護成本過高,不少產品初期團隊根本不具有這樣的資源,可是若是開始就設計一個單體架構可能又知足不了將來業務的發展.若是微服務架構是一個計劃式設計的話,那單體架構就是一個演進式架構。可是這種演進的成本很高,甚至面臨着重作的風險。代理
若是咱們引入六邊形架構這種最小化設計,再結合api容器就能夠幾乎0成本的將單體架構切換到微服務.
PS:每一個架構演化均可以說不少,網上已經有不少這種說明,這裏就沒有詳細的說明,有興趣的能夠留言討論.