架構設計，一直就是軟件業界中顯得高深的名詞之一，會造成很多的人對于它都充滿了神秘感，但接觸過幾年軟件業的人很多時候又會覺得軟件架構原來不過如此，特別是看到一些架構設計文檔后更是得出如此的感想，但真的是如此嗎？也許是因為那些架構設計文檔并沒有起到它們真正的作用，只是拿來糊糊人的吧，架構設計文檔最重要的是要能對系統的軟件設計做出指導，做出規范性的約束，不談這些，重點還是談架構設計。
首先我們想想為什么要做架構設計呢？可能很多人會說在他們的系統中就是沒做架構設計的，但其實不管你有沒有做架構設計，你的腦海中或多或少都是已經考慮過的，只是也許沒有變的那么的正規，首先，我們來看看什么是架構，架構作為系統的骨架而存在，正因為這個原因才說所有的系統都是有架構的，有架構自然就有設計，盡管它也許只是浮在你腦海中的某個東西而已，從架構中我們可以看到對于整個系統的支持，包括系統的各個方面，業務需求、用戶需求以及功能需求的滿足，架構設計能幫助你站在高的角度來看待、分析整個系統，在架構設計中通常采用OOAD的方法來幫助完成架構設計，想想沒有架構設計的系統是什么系統呢？是一個沒有骨架的系統，一個人沒有骨架會怎么樣呢？那么，同樣，一個系統呢？一個系統沒有骨架甚至比一個人沒有骨架更為嚴重。
那么我們怎么去做架構設計呢？架構來源于需求，是在對需求進行分析、設計的情況下產生出來的，一個系統的需求通常非常的復雜，那么怎么樣去產生它的架構呢？我們知道軟件設計中最重要的就是抽象，其實說的更為專業應該是采用OO的思想，在過去采用的是面向過程的思想，這里就不再去討論為什么要采用OO了，OO中幾個重要的思想就是抽象、繼承、封裝，在分析和設計時我們同樣要進行遵循，分析過程是對需求進行分析，產生出概念模型，此概念模型和設計的模型是不同的，概念模型停留于業務層面，而設計模型則為對此概念模型提出技術級別的解決實現方案，在經歷了分析、設計過程后我們的系統架構就得以誕生，系統架構作為系統的一部分，同樣要面臨需求變化所帶來的影響，而同時系統架構作為系統最為基礎的部分，是要盡量減少變化所帶來的影響的，要解決這個矛盾，在做架構設計時就要多多的考慮，可以采用使用模式、接口化等多種方式。
大家也許也看出，在寫這篇blog我表達的并不是很清楚，確實，因為我自己都還有不少迷惑的地方，雖然寫過那么幾篇架構設計文檔，做過那么幾次架構設計，但一直以來就覺得以前做的架構設計不是那么的到位，通常有些部分還是平白無故就誕生出來了，而這些主要是依據的自己的經驗，而不是對需求的分析，這對于系統架構而言是致命的，覺得現在也是靜下心來好好考慮的時候了，同時也會多多的參看架構設計理論方面的書籍，結合實踐提升自己在架構設計上的水平，所以將這篇blog的標題定位了思考之一，在思考的有些進展的時候會將這個繼續的寫下去，也希望能得到更多的做過架構設計的同仁、前輩的指點。