很多典型的軟件架構文檔模板用來編寫輔助文檔實際上沒有那麼糟，但各個部分的名字往往令人困惑。如果你看了我剛才展示的標題清單，可能會好奇，典型的軟件架構「視圖」在哪裡。
如果你以前沒見看過這些，就有很多不同的方式來察看一個軟件系統。例子有IEEE 14714 、ISO/IEC/IEEE 42010 5 、菲利浦·克魯西騰（Philippe Kruchten）6 的4+1模型7 等。它們的共同之處是都給一個軟件系統提供了不同的「視圖」來描述不同的方面。比如，通常有「邏輯視圖」、「物理視圖」、「開發視圖」，等等。
4 http://en.wikipedia.org/wiki/IEEE_1471
5 http://en.wikipedia.org/wiki/ISO/IEC_42010
6 加拿大軟件工程師，英屬哥倫比亞大學教授，http://en.wikipedia.org/wiki/Philippe_Kruchten 。——譯者注
7 http://en.wikipedia.org/wiki/4%2B1_architectural_view_model
我發現很多方法都有個大問題，如果人們不熟悉方法使用的術語，很快就會變得困惑。比如，我聽過到有人爭論「概念視圖」和「邏輯視圖」有什麼不同。我們還是不要開始關於是否允許技術出現在邏輯視圖的問題吧！觀點也很重要。如果我是一個軟件開發者，「開發視圖」是不是就是代碼，或是說那叫「實施視圖」？但「物理視圖」又是什麼？我的意思是，代碼就是物理輸出，對吧？但對基礎設施架構師而言，「物理視圖」又是另一個意思。但是，假如目標部署環境是虛擬的而非物理的呢？
我的建議是，不管你如何編寫文檔，只要明白你想傳達的是什麼，並相應地給各部分命名。解決術語問題的一個選項是確保團隊中每個人對各種架構視圖是什麼都能找到清晰的定義。在這方面，我高度推薦約恩·伍茲（Eoin Woods）和尼克·羅桑斯基（Nick Rozanski）所著的《軟件系統架構》8 。另一個方法是就是將各個部分重新命名來消除歧義。
8 http://www.viewpoints-and-perspectives.info