一、開篇
我們在學習新的技術或者解決某些業務和技術問題時，很多同學都會一股腦的鑽進細節和思考如何快速解決，久而久之形成了點狀的知識結構和認知體系。如同我經常在面試一些中高級程序員的時候，經常會問一個問題：java 的知識體系是什么/java 的組成是什么。也正如自己所預期的那樣，經常有候選人不知所雲，用我高中一位班主任的口頭禪：茫茫然不知其所以然。於是我們得到一個結論：體系的思考和學習是如此的重要，以至於另當今浮躁的社會和風氣讓那些可以沉下來的程序員無形中少了很多競爭對手。
二、回歸主題
我們回歸本次的主題，首先了解應用架構圖的作用是什么：主要是用來描述應用架構的，具體體現在描述系統的組成和框架。這種解釋即清楚又抽象，本文我們着重從應用的維度去了解如何構建我們的應用架構圖，以及什么是應用架構圖，那到底是什么應用？
百度百科給出了很多種解釋，在眾多的解釋中，給到我比較有啟發作用的是數字布魯姆的信息化工具集合圖示中，按照認知領域創造六個層次，分別是識記、領會、應用、分析、評價、創造，其相互之間環環相扣，互相制約且相互依存。在這六大層次中，應用可以說是有着核心地位，有着承上啟下和最終價值呈現的作用。
撇開數字布魯姆理論本身的解釋我們可以這么理解，對於某個企業在使用某個領域開展生產活動，通過分析和評價我們得知該領域投入市場發揮的作用和產生的價值，最終決定着企業是否需要通過創新等手段更進一步挖掘其更大的價值然后再給企業帶來更高的循環價值，如果采用更為官方或者抽象的語言就是對於企業來說，決定企業的發展戰略方向和企業經營的業務模式，對於一個系統來說決定着系統的價值有多大，用戶的評價是不是好未來是否還需要將該系統進行更大范圍的推廣甚至擴大規模，這是向上。
向下的作用，我們理解只有識記、領會之后，才有可能進入應用層次。識記是一個心理學上的詞語，它是記憶的一個重要的緩解，通過反復的感知的過程，在達到記憶條件后，開始領會，即領略事務中蘊含的道理並對其深有體會。那我們記憶什么東西，我們去感知去領會什么東西變的尤為重要，而這不難想象，對於一個系統而言完全取決於系統的應用場景事什么，說到底總結下來還是應用二字。
我們來看一下對於應用架構百度百科的解是：
應用架構（Application Architecture）是描述了IT系統功能和技術實現的內容。應用架構分為以下兩個不同的層次：企業級別的應用架構、單個系統的應用架構......
無論企業級別的應用架構還是單個系統的應用架構，最終都是通過系統功能和技術兩個維度來闡述。這個時候就會出現些困惑，我們在學習或者畫業務架構圖甚至產品架構圖的時候，也會出現系統功能的概況性內容，也就是說無論是在以系統功能描述為核心的應用架構，還是在業務架構中都會出現帶有業務語言的功能描述字樣，例如財務管理、營銷管理，這些簡化的功能描述短語無論在應用架構還是在業務架構中都會出現，對於初識架構以及開始自己着手畫架構的同學來說，難免會出現畫着畫着四不像的情況，甚至會出現自己畫完以后當別人問起，你這個圖是那種架構圖，於是內心深處本來想說畫業務架構畫着畫着不再是真正意義上的業務架構，那到底該如何真正區分各種架構呢？
我們程序員經常說的系統架構，也就是我們講的企業架構， TOGAF 做了如下的描述：
-
業務架構：定義業務戰略、治理、組織和關鍵業務流程
-
應用架構：應用之間結構和交互的描述
-
數據架構： 描述組織的邏輯與物理數據資產及數據管理資源的結構
-
技術架構：描述支持業務、數據和應用服務部署所需的邏輯的軟件與硬件能力，包括 IT 基礎設施、中間件、網絡、通信、處理和標准等
經過 TOGAF 的一系列描述，似乎又冒出一個問題，技術架構和以技術為核心的應用架構的區別又在哪里呢？
所有的疑問和不解的答案歸結於兩個字：領域。
一直以來我們一直尊崇或者向往的 DDD 領域驅動編程，看似高大上，實則在絕對多數公司是沒有真正執行起來的，其原因表面看起來是使用了 DDD 模式進行開發后，整個開發的工作了變的巨大無比，工作了可能雙倍不止的增加，而通常業務發展又是及其迅速的，業務的變更和改動也是頻繁且沒有道理的，於是在軟件公司最終從上到下認為 DDD 是個好東西，但是無法執行。而個人認為深層次的原因還是對領域的認識和諸多誤解，甚至是不解以及無知而導致的不認同，我們常說業務和技術要有共同的語言，即通過領域模型這種介於業務和技術之間的事務來達到認知一致，沒錯，道理非常淺顯卻依舊無法執行。在 DDD 領域驅動編程中，想要真正的執行所有的核心關注點都在領域模型上，一個相對穩定的相對完善的領域模型是如此的重要（至少是在未來相當一段時間內），特別是對 DDD 來說，就現實而言如果連業務自身都沒辦法穩定或者通過討論確當一個企業、一個產品、一個項目未來一段時間內可預見性的時間並加以預判，何來穩定的領域模型，何來 DDD 的落地。而業務和產品往往都是暫時這么設計，將來遇到問題再改，當然技術時長也這樣，但是技術的暫時設計所帶來的影響從 DDD 的落地來說是有兜底方案相對的不會反過來影響業務和產品，而業務和產品的兜底方案是技術按需改代碼。
無論是對各種架構圖的迷惑還是對 DDD 無法真正落地的簡單分析，根本原因還是大家對領域這一概念的模糊，對領域在軟件設計、開發過程中加以忽視導致的。大家可以反思一下，在自己過往的編程經歷中，有多少是對領域加以重視，那不重視的體現就是接到需求后上來就干，好一點的做一做技術方案然后就開搞，需求有變更再改技術方案最后改代碼。
在我的印象中在這方面我們所崇拜的大廠做的確實不錯，現在慢慢的很多效益不錯的企業也開始注重領域方面的設計，這種設計不僅僅是技術，也設計到了業務和產品，領域邊界的確定與不確定波及的不僅僅是技術團隊，乃至整個企業的組織架構都會有非常深遠的影響。
三、總結
紙上得來終覺淺，絕知此事要躬行。在我們畫應用架構圖或者其他系統架構圖時，我們要首先明白每種架構圖的領域邊界到底是什么，是為了解決什么業務場景和問題，否則就會出現四不像的情況。於是我們就需要知道領域到底是怎么回事，領域建模、領域驅動這又是一個值得學習、深思、討論和實際落地的話題。
回到我們的疑問，您知道怎么畫應用架構圖嗎？
-
第一步：通過領域邊界搞明白各種系統架構圖的邊界到底是什么。
-
第二步：自己是真的要花應用架構圖嗎？是要畫以系統功能為核心的應用架構圖還是以技術為核心的應用架構圖。
-
第三步：定義各個系統或者功能的邊界和定義、系統間的關聯關系和約束條件，對下依賴什么，對上供誰使用達到什么效果。