“

首先，這篇文章肯定會得罪一些人

“

其次，此文只代表我個人的意見，僅供參考

從分層說起

談到系統架構的分層和系統領域邊界的劃分，每個架構師，每個技術經理，甚至每個程序員都有自己的一套想法。無論是怎么樣的劃分方案，總體的目標始終是一致的，打造一個高性能，高可用，高可擴展，高安全性的系統，甚至會附加上一大堆的專業名詞，例如：高度一致性，可重用性，冪等性，兼容性 等等。對于最終用戶來說，無論系統怎么樣架構設計，穩定性是第一位的。假如系統三天兩頭打不開，報500服務器錯誤，程序員豈不是天天要被祭天？

從很久之前的面向過程編程模式，到現在的面向對象設計，微服務架構方案，都體現著架構設計一直在追求更加極致的設計之美。而這種美要歸功于系統的分層設計，小到類的職責劃分，大到系統的分布式部署。

系統為什么一定要做分層呢？至于系統領域的劃分，本質上也是一種分層設計的體現思想。

分層是軟件工程中一種常見的設計方式，它根據整個系統的職責鏈把系統邏輯上拆分為多個層，每個層都有相對明確的獨立的職責，多個層通過協調提供完整的功能。至于每層負責什么職責，軟件工程學并沒有明確的定義，系統的設計者可以根據系統特點來具體劃分，比如：最常見的三層架構設計，把整個系統劃分為：

• UI層，主要負責用戶UI的職責

• 業務層，主要負責業務邏輯相關職責

• 數據持久化層，主要負責數據的持久化，落盤操作

image

還有我們耳熟能詳的OSI網絡模型，它把整個網絡劃分為了七層，每層都有相對明確的職責，但是還有另外一種劃分方式把網絡模型劃分為四層，這是根據不同職責來劃分網絡的典型案例。

軟件設計采用分層設計算是一種工程學，它把整體系統劃分為不同的層，之后采用不同的依賴方式來組織功能，帶來了很多優勢

• 每層的職責明確，而且依賴關系明確

• 每層都可以復用，減少了代碼重復率

• 每層都可以相對獨立的做修改，擴展等，不會影響其他層

看到不少技術經理乃至架構師一直鄙視使用三層架構的程序員，我覺得你需要反思一下。最簡單的三層架構模式并非優勢全無，據我所知，在快速應對中小系統開發的時候，三層架構仍然是首選。不要整天拿著所謂的DDD說事，DDD也不是銀彈，簡單的三層架構，甚至貧血模型開發模式也有自己的優勢，更何況一些人高舉DDD的“聚合根”，“值類型”等概念，其實并未真正理解其含義和設計理念，自以為看了幾篇DDD的文章，就可以妄自吹噓自己精通DDD，領域模型開發確實是好的開發理念，但是它也有自己的劣勢，不是任何系統用DDD開發都是最優的，更何況那些沒有實際DDD開發經驗的“高層”。

系統拆分

雖然分層設計優勢很明顯，但是隨著系統業務越來越復雜，就面臨著層次劃分越來越多的窘態。這也是系統發展的一個必然結果，也是單體應用的必然瓶頸。所以系統按照業務拆分是業務發展到一定階段的結果，而并非架構師主觀意愿的結果。隨著子系統越來越多，部署和運維工作也隨著越來越多，所以自動化的部署需求也隨之出現，為了更好的實現每個系統的可擴展性，穩定性，可用性等軟性需求，kubernetes也越來越受到追捧。

其實系統拆分是一個很泛的概念，業界并沒有實際的拆分原則，只是大部分人喜歡以業務為維度來進行拆分，實際證明按照業務拆分也是正確的。被拆分的不止是業務邏輯的代碼，包括業務的數據庫等也會被徹底物理隔離，因為只有這樣才可以做到真正的高內聚，低耦合。

image

架構設計

當每個服務都可以根據自身業務量來進行橫向擴展或者縱向擴展的時候，就可以體現出微服務的優勢。而具體的系統架構設計決定著這個服務是否可以靈活的應對多變的業務需求，說到底，我們又回到怎樣設計單體系統的話題上來了。其實設計好單體架構并不比分布式系統容易，一個好的單體系統同樣也需要設計模式，數據結構，算法和抽象。前面所說的三層架構是其中一種選擇。

系統的設計離不開業務，任何脫離業務的系統架構設計都是耍流氓。設計一個靈活的系統需要對業務的變化點進行正確的識別，然后進行抽象，比如：注冊新用戶的時候，需要給用戶發送短信歡迎語，其實這是一個業務的變化點，因為產品不知道哪天會有一個發送郵件的歡迎語，甚至如果關注了公眾號，會發送公眾號消息。

三層架構在應對大型系統的時候之所以力不從心，是因為他并不是按照業務的對象進行分層抽象，而現在流行的DDD更加貼近現實世界中的抽象層次，所以DDD在大型系統中更加游刃有余。其中有一種六邊形的架構理論值得我們學習。

六邊形架構設計

image

六邊形架構設計本質上還是一種分層架構設計方案，但是它不同于傳統的三層架構，傳統的三層架構自上而下逐層依賴，而六邊形架構設計采用了內部外部的分層思想，它把業務的領域模型最為最核心的概念，然后擴展出外層的應用層，其實領域模型和應用層就是系統的業務層。

內部通過端口和外部系統通信，端口代表了一定協議，以API呈現。一個端口可能對應多個外部系統，不同的外部系統需要使用不同的適配器，適配器負責對協議進行轉換。這樣就使得應用程序能夠以一致的方式被用戶、程序、自動化測試、批處理腳本所驅動，并且，可以在與實際運行的設備和數據庫相隔離的情況下開發和測試。

• 領域層：領域層是業務最核心的概念，包括領域對象的狀態，規則，行為等。

• 應用層：定義了系統可以完成的功能，它通過協調多個領域對象來完成業務邏輯，這一層會包含事務的管理。

• 輸入端口：用于接收外部系統的輸入，可以認為它是暴露在外邊的接口

• 輸出端口：為系統獲取外部服務提供支持，如獲取持久化狀態、對結果進行持久化，或者發布領域狀態的變更通知（如領域事件）。系統作為服務的消費者獲取服務是對外的接口（數據庫、緩存、消息隊列、RPC調用）等都可以看成是輸入端口。

六邊形理論從一開始就強調把中心放在業務邏輯上，外部的端口存在可變性，可替換性，這是依賴倒置規則的體現。下面就以用戶注冊業務來模擬一下

首先為核心的用戶領域模型,以及模型的行為，其中持久化數據的行為依賴于接口

//用戶領域對象public?class?UserDomain{public?int?UserId?{?get;?set;??}public?string?UserName?{?get;?set;?}//注冊新用戶行為public?int?UpdateName(string?name){IUserDomainRepositoryAdpater?resAdapter?=?ioc方式獲取注入的實例/或者其他渠道;return?resAdapter.UpdateUserName(this.UserId,name);}}

然后是用戶的應用,其中給用戶發送歡迎語的行為依賴于接口

?public?class?UserApplication{public?int?UpdateuserName(int?userId,string?name){UserDomain?user?=?new?UserDomain()?{?UserId?=?userId,?UserName?=?name?};user.UpdateName("新用戶名");ISendMessageAdpater?sendMessage?=?ioc獲取實例;sendMessage.SendMessage(userId.ToString(),"新用戶注冊");}}//發送消息的適配器public?interface?ISendMessageAdpater{//給用戶發送消息void?SendMessage(string?user,string?content);}

到此為止，用戶核心業務已經編寫完畢，可以看到，其中業務的變化點都是依賴于接口，對應到六邊形理論中，對應的就是各種adapter，接下來只要把各種適配器實現，然后注入（安裝）到系統，整個系統就可以運行起來了。

//外部的adapter的實現public?class?UserDomainRepositoryAdpater:?IUserDomainRepositoryAdpater{public?int?UpdateUserName(int?userId,?string?name){//具體的sql執行過程}} public?class?SendEmailAdpater:?ISendMessageAdpater{//給用戶發送郵件public?void?SendMessage(string?user,?string?content){}}public?class?SendPhoneCodeAdpater?:?ISendMessageAdpater{//給用戶發送短信public?void?SendMessage(string?user,?string?content){}}

不難看出，六邊形理論其實是抽象業務模型+面型接口編程的有效組合，當然真正的項目中還有可能涉及到很多設計模式相關的設計理念。對應到平時開發中，mvc的controller層已然變成六邊形的輸入adapter的一種，它負責請求業務提供的接口來實現系統業務。

程序員過關斬將--真的可以用版本號的方式來保證MQ消費消息的冪等性？

程序員過關斬將--搞定秒殺，只需要這幾步！！

程序員修神之路--分布式系統使用網關到底是好還是壞？

程序員修神之路--它可能是分布式系統中最重要的樞紐

總結

以上是生活随笔為你收集整理的程序员过关斩将--从未停止过的系统架构设计步伐的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。