架構設計系列文章，請參見連接。

前言：對于軟件的認知層次代表著不同的專業程度，也代表著不同層次需要完成的工作的不同。在架構設計過程中需要有效的利用分層的認知，對不同層次的問題進行有針對性的解決確定。

1. 背景

在架構設計與實現過程中，需要對軟件系統做全局的分析與考慮以求全局的認知。在分析和考慮過程中軟件的不同層次都有獨特的問題。為了在設計階段做出更全面的決策，以解決絕大部分實現過程中可能遇到的問題，需要對軟件開發過程中不同的層次的工作內容進行具體的分析。

所以需要對軟件設計與決策提供全局框架，并把握每個層次的關鍵點。

軟件層次

2. 層次

可以將軟件的實現過程分為如圖的幾個層次，軟件從業人員也可以根據圖中的層次進行劃分。對于軟件實現層級的劃分也印證了現在的軟件設計與實現已經超越了算法和數據解構，對系統結構的設計與治理成為架構設計的重點。分層結構如上圖所示，軟件分為7個層次：

2.1 代碼=數據結構+算法：

在學校學軟件的時候有一種普遍的認知：軟件=算法+數據結構。在當時（零幾年）沒有微服務、沒有DevOps、沒有超大互聯網企業，那會對于軟件的認識可能就是單體，mfc這種模式的軟件。所以，將軟件認為就是數據結構加算法即可解決絕大部分問題。

其實這樣的認知也是受到時代的局限。在大部分軟件都是小型的C/S、B/S的時候，當時最大的問題還是怎樣開發一套業務系統的年代，不會涉及到分布式系統的情況下能做出來就很不錯了。更不用談對于軟件的認知。

2.2 程序=代碼+設計模式：

在代碼使用設計模式。為什么？

軟件規模在不斷的擴大，不斷的發展。而在這個過程中遇到的規模化代碼的管理問題，可擴展問題，可修改性問題。急需為軟件的持續發展提供一種解決方式，讓軟件規模增長提供管理的方法。

這時小規模的問題通用解決方案可以使用設計模式進行管理。因為每一個設計模式都是解決代碼規模化的一部分問題。

2.3 模塊=程序+分包模式：

這是伏羲一畫開天式的創舉，但很少有人提到分包模式。因為現在的mvc，mvp，acp等已經很流行而且已經深入人心。所以分包模式對于現在的開發已經很平常。但是分包模式是第一次進行了高內聚低耦合的實踐。

2.4 軟件=模塊+架構模式：

設計模式之上的架構模式。為什么？

到現在為止并沒有對軟件系統中的工作內容進行劃分，例如：MVC的各種變種。軟件層之下的主要是管理代碼，代碼編寫的內容。而架構模式管理的是對于復雜業務下模塊的拆分，模塊的關系，代碼的復用的工作。這部分內容之所以需要做是因為意識到軟件的工作中并不是所有的工作都需要用到算法和數據結構，需要將不同的業務之間隔離并確定業務之間的關系。

所以架構模式負責的是給業務分包、模塊。讓軟件中的每一個模塊都可以做到單一職責。

2.5 系統=軟件+架構風格：

架構模式之上的架構風格。為什么？

上一個層次中已經說明通過使用分包、模塊化的方法進行模塊的職責的劃分。那么一個系統應該以怎樣的方式將系統中的服務鏈接起來。

在常見的架構的定義中有一種：一個程序或計算機系統的軟件體系結構包括一個或一組軟件構件、軟件構件的外部的可見特性及其相互關系。

2.6 平臺=系統+企業架構：

架構風格之上的企業架構。為什么？

軟件的最終目標是什么？按照作者理解應該是解決人們現實中的切實問題，不管是提升效率、降低成本、提升便利性還是提供特定幫助都是可以通過計算機的計算能力來解決的事情。抱著這個目標去實現

傳說中的EA，它最主要的解決問題是：為了解決IT與業務對齊、業務和戰略對齊問題。

2.7 企業架構

企業架構有多種方法論，也有不同層面的解決方案。例如：EA可以有togaf，zachman，dodaf等。產品開發方法有ipd，精益等方法。

我個人一般喜歡以：理想、目標、原則、方法這幾個方向去分析一個公司是否真正的解決了現實問題。并根據四個元素去確認公司的目標與個人目標的一致性。

3. 總結

每個層次的認知都是對的，并沒有錯誤一說。這里最主要的區別是你處在什么階段就會認知到什么樣的軟件。行業所處的階段也會影響從業者對于這個行業的認知，就像文中所說的一樣認知是受到時代的局限。

就像《演進式架構》中所說的：適度的重復是有益的。而不像之前人們認為DRY，不能重復任何東西。所以，站在鄧寧克魯格的開悟之坡的人并不會去嘲笑處在愚昧之峰的人。

再比如《軟件架構：架構模式、特征及實踐指南》中所說的：適合的才是最好的。很多時候沒有對錯，只有合適，在馬丁富勒的《單體優先》中也有類似的描述。

在這里說這么多要證明的是：認知處在任何階段都是正常的，不過需要不斷的提升認知。