架構(gòu)設(shè)計(jì)系列文章肘交，請參見連接谦屑。
前言：對于軟件的認(rèn)知層次代表著不同的專業(yè)程度，也代表著不同層次需要完成的工作的不同朴皆。在架構(gòu)設(shè)計(jì)過程中需要有效的利用分層的認(rèn)知贴彼，對不同層次的問題進(jìn)行有針對性的解決確定。
1. 背景
在架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)過程中窍育，需要對軟件系統(tǒng)做全局的分析與考慮以求全局的認(rèn)知卡睦。在分析和考慮過程中軟件的不同層次都有獨(dú)特的問題。為了在設(shè)計(jì)階段做出更全面的決策漱抓，以解決絕大部分實(shí)現(xiàn)過程中可能遇到的問題表锻，需要對軟件開發(fā)過程中不同的層次的工作內(nèi)容進(jìn)行具體的分析。
所以需要對軟件設(shè)計(jì)與決策提供全局框架辽旋，并把握每個(gè)層次的關(guān)鍵點(diǎn)浩嫌。
2. 層次
可以將軟件的實(shí)現(xiàn)過程分為如圖的幾個(gè)層次，軟件從業(yè)人員也可以根據(jù)圖中的層次進(jìn)行劃分补胚。對于軟件實(shí)現(xiàn)層級的劃分也印證了現(xiàn)在的軟件設(shè)計(jì)與實(shí)現(xiàn)已經(jīng)超越了算法和數(shù)據(jù)解構(gòu)码耐，對系統(tǒng)結(jié)構(gòu)的設(shè)計(jì)與治理成為架構(gòu)設(shè)計(jì)的重點(diǎn)。分層結(jié)構(gòu)如上圖所示溶其，軟件分為7個(gè)層次：
2.1 代碼=數(shù)據(jù)結(jié)構(gòu)+算法：
在學(xué)校學(xué)軟件的時(shí)候有一種普遍的認(rèn)知：軟件=算法+數(shù)據(jù)結(jié)構(gòu)骚腥。在當(dāng)時(shí)（零幾年）沒有微服務(wù)、沒有DevOps瓶逃、沒有超大互聯(lián)網(wǎng)企業(yè)束铭，那會(huì)對于軟件的認(rèn)識可能就是單體，mfc這種模式的軟件厢绝。所以契沫，將軟件認(rèn)為就是數(shù)據(jù)結(jié)構(gòu)加算法即可解決絕大部分問題。
其實(shí)這樣的認(rèn)知也是受到時(shí)代的局限昔汉。在大部分軟件都是小型的C/S懈万、B/S的時(shí)候，當(dāng)時(shí)最大的問題還是怎樣開發(fā)一套業(yè)務(wù)系統(tǒng)的年代靶病，不會(huì)涉及到分布式系統(tǒng)的情況下能做出來就很不錯(cuò)了会通。更不用談對于軟件的認(rèn)知。
2.2 程序=代碼+設(shè)計(jì)模式：
在代碼使用設(shè)計(jì)模式娄周。為什么涕侈？
軟件規(guī)模在不斷的擴(kuò)大，不斷的發(fā)展煤辨。而在這個(gè)過程中遇到的規(guī)纳烟危化代碼的管理問題木张，可擴(kuò)展問題，可修改性問題调违。急需為軟件的持續(xù)發(fā)展提供一種解決方式窟哺，讓軟件規(guī)模增長提供管理的方法。
這時(shí)小規(guī)模的問題通用解決方案可以使用設(shè)計(jì)模式進(jìn)行管理技肩。因?yàn)槊恳粋€(gè)設(shè)計(jì)模式都是解決代碼規(guī)那夜欤化的一部分問題。
2.3 模塊=程序+分包模式：
這是伏羲一畫開天式的創(chuàng)舉虚婿，但很少有人提到分包模式旋奢。因?yàn)楝F(xiàn)在的mvc，mvp然痊，acp等已經(jīng)很流行而且已經(jīng)深入人心至朗。所以分包模式對于現(xiàn)在的開發(fā)已經(jīng)很平常。但是分包模式是第一次進(jìn)行了高內(nèi)聚低耦合的實(shí)踐剧浸。
2.4 軟件=模塊+架構(gòu)模式：
設(shè)計(jì)模式之上的架構(gòu)模式锹引。為什么？
到現(xiàn)在為止并沒有對軟件系統(tǒng)中的工作內(nèi)容進(jìn)行劃分唆香，例如：MVC的各種變種嫌变。軟件層之下的主要是管理代碼，代碼編寫的內(nèi)容躬它。而架構(gòu)模式管理的是對于復(fù)雜業(yè)務(wù)下模塊的拆分腾啥，模塊的關(guān)系，代碼的復(fù)用的工作冯吓。這部分內(nèi)容之所以需要做是因?yàn)橐庾R到軟件的工作中并不是所有的工作都需要用到算法和數(shù)據(jù)結(jié)構(gòu)倘待，需要將不同的業(yè)務(wù)之間隔離并確定業(yè)務(wù)之間的關(guān)系。
所以架構(gòu)模式負(fù)責(zé)的是給業(yè)務(wù)分包组贺、模塊凸舵。讓軟件中的每一個(gè)模塊都可以做到單一職責(zé)。
2.5 系統(tǒng)=軟件+架構(gòu)風(fēng)格：
架構(gòu)模式之上的架構(gòu)風(fēng)格失尖。為什么贞间？
上一個(gè)層次中已經(jīng)說明通過使用分包、模塊化的方法進(jìn)行模塊的職責(zé)的劃分雹仿。那么一個(gè)系統(tǒng)應(yīng)該以怎樣的方式將系統(tǒng)中的服務(wù)鏈接起來。
在常見的架構(gòu)的定義中有一種：一個(gè)程序或計(jì)算機(jī)系統(tǒng)的軟件體系結(jié)構(gòu)包括一個(gè)或一組軟件構(gòu)件整以、軟件構(gòu)件的外部的可見特性及其相互關(guān)系胧辽。
2.6 平臺=系統(tǒng)+企業(yè)架構(gòu)：
架構(gòu)風(fēng)格之上的企業(yè)架構(gòu)。為什么公黑？
軟件的最終目標(biāo)是什么邑商？按照作者理解應(yīng)該是解決人們現(xiàn)實(shí)中的切實(shí)問題摄咆，不管是提升效率、降低成本人断、提升便利性還是提供特定幫助都是可以通過計(jì)算機(jī)的計(jì)算能力來解決的事情吭从。抱著這個(gè)目標(biāo)去實(shí)現(xiàn)
傳說中的EA，它最主要的解決問題是：為了解決IT與業(yè)務(wù)對齊恶迈、業(yè)務(wù)和戰(zhàn)略對齊問題涩金。
2.7 企業(yè)架構(gòu)
企業(yè)架構(gòu)有多種方法論，也有不同層面的解決方案暇仲。例如：EA可以有togaf步做，zachman，dodaf等奈附。產(chǎn)品開發(fā)方法有ipd全度，精益等方法。
我個(gè)人一般喜歡以：理想斥滤、目標(biāo)将鸵、原則、方法這幾個(gè)方向去分析一個(gè)公司是否真正的解決了現(xiàn)實(shí)問題佑颇。并根據(jù)四個(gè)元素去確認(rèn)公司的目標(biāo)與個(gè)人目標(biāo)的一致性顶掉。
3. 總結(jié)
每個(gè)層次的認(rèn)知都是對的，并沒有錯(cuò)誤一說漩符。這里最主要的區(qū)別是你處在什么階段就會(huì)認(rèn)知到什么樣的軟件一喘。行業(yè)所處的階段也會(huì)影響從業(yè)者對于這個(gè)行業(yè)的認(rèn)知，就像文中所說的一樣認(rèn)知是受到時(shí)代的局限嗜暴。
就像《演進(jìn)式架構(gòu)》中所說的：適度的重復(fù)是有益的凸克。而不像之前人們認(rèn)為DRY，不能重復(fù)任何東西闷沥。所以萎战，站在鄧寧克魯格的開悟之坡的人并不會(huì)去嘲笑處在愚昧之峰的人。
再比如《軟件架構(gòu)：架構(gòu)模式舆逃、特征及實(shí)踐指南》中所說的：適合的才是最好的蚂维。很多時(shí)候沒有對錯(cuò)，只有合適路狮，在馬丁富勒的《單體優(yōu)先》中也有類似的描述虫啥。
在這里說這么多要證明的是：認(rèn)知處在任何階段都是正常的，不過需要不斷的提升認(rèn)知奄妨。
