《.NET應用架構設計：原則、模式與實踐》新書部落格--試讀-1.1-正确認識軟體架構第1部分 架構與設計的原則和模式第1章 架構與設計的流程和核心概念

    很多的開發人員（不管其處于那個階層）對架構設計特别着迷，甚至達到了癡迷和神往的地步。不過，學習程式設計相對而言可能是一件比較容易的事情（隻要有好的學習态度和程式設計習慣，然後掌握一定的技術，很快就可以成為一個比較出色的開發人員），若要想練就架構設計的能力卻不是那麼容易。

    架構，近似于藝術，有着對美的要求和對完美的追求，但它又和藝術不一樣，比如：架構設計可以在軟體中實實在在的展現出來，一個合适的架構會讓系統有很好的靈活性和伸縮性，并且會使軟體開發有良性循環；相反，一個不合适的架構則很容易導緻軟體在變化的需求中崩潰，甚至會讓開發進入“死亡行軍”的狀況中。就因為如此，架構才會顯得如此神秘，同時又讓人難舍對它的追求。

    本書将會和大家一起探讨有關架構的話題，不過，架構相關内容覆寫面很廣，想要通過一本書就把它講清楚幾乎是不可能的，本書以實踐角度出發，着重講述了架構設計中可以采用的原則和模式，以及一些思想方面，希望在大家的架構之路上能夠獻上一點綿薄之力。

    本章是全書中理論最多的一章，主要是希望大家對架構師、架構設計有一定的了解，為了解後續的章節打下基礎。

    不同的人對架構有着不一樣的了解。無論是在建築行業、軟體行業，還是在網絡或書本上，“架構”一詞有着各種各樣的解釋。在程式設計的世界中，很多對架構的解釋都是從技術的層面來定義的，而且在不同的技術或平台上面，對架構的定義又不太一樣，甚至有些定義和了解失去了其原本的核心意思，這就使得部分架構學習者感到迷茫。

    如果認為“架構”是一個簡單的實體，能夠用一份文檔或一張圖紙來描述，那麼你就錯了。确實，架構師在為系統建立架構時經常要做出很多與設計相關的決定，而且會以用文檔的形式記錄下來，但是架構和文檔又不是等同的，之是以要以文檔的形式儲存，主要是為了便于以後對這些設計決定進行稽核和修改，并且将其作為建構軟體時的限制和指導。

    首先，讓我們來看看架構的一個定義：

    軟體架構是對系統的高層視角，或者是對系統的抽象。它關注的是某些對完成這個系統有着最大幫助的方面，例如：可用性、穩定性，以及靈活性。同時，架構對如何達到這些目的給出了指導和限制。

    如果要用最簡單的方式來了解上面的定義，可以這樣說：軟體架構就是軟體系統的一張藍圖。

    下面我們用一個比較淺顯的類比來說明這個“藍圖”的含義。

    相信大家對冶金行業中的“澆築”或多或少有一些了解。澆築就是把液體材料倒在一個有着特定形狀的沙模中，然後等液體冷卻之後得到想要的産品或特定形狀材料的過程。在這個過程中，盛放液體的沙模引導着液體慢慢成形，最後得到我們預想的結果。

   其中，有一點要注意的是，沙模的特性（比如形狀和大小）和倒入其中的液體是沒有任何聯系的，換句話說：沙模和液體是完全分離的，但是沙模又必須和液體在一起才能生産出所要的産品。

    架構就好比上面例子中的沙模，軟體項目就好比用于澆築的液體。正如澆築一樣，架構引導着項目，最後得到了我們想要的結果。同時，我們也可以得出：軟體的架構和實作這個系統的代碼是沒有很嚴格的關系的，這也就是我們常說的架構是平台無關的。架構可確定開發的過程在一定的限制或規則下進行。

    對于沙模來說，如果沒有澆築液體的存在，它基本就沒有任何作用；架構也是立足項目的特定需求來設計的！

本文轉自yanyangtian51CTO部落格，原文連結： http://blog.51cto.com/yanyangtian/745261，如需轉載請自行聯系原作者