軟件構架是一個容易理解的概念，但多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難，在設計中更容易忽視軟件架構的巨大作用，所以我將在以下的內容中解釋什么是軟件架構以及如何提高架構的性能等軟件設計中的容易被忽視的問題。
一、什么是架構
1. 和架構相關的幾個問題域
架構需要解決的非業務問題域包括如下：
A 系統目標：系統性能，穩定性.
C.項目過程：需求的不確定性和開發過程的團隊協作性
不同的問題域，解決之道也不相同!而同一問題域的不同層次的要求，解決之道也不盡相同。
2. 什么是架構
架構到底是啥，愚以為下面的這段英文描述的很清楚。
That's like asking, what is culture? Culture is the way you do things in a group of people. Architecture is the way you do things in a software product. You could argue by analogy, then, that architecture is to a software product as culture is to a team. It is how that team has established and chosen its conventions，
Which leads us inevitably to the question of “goodness”? How do you know if an architecture is good? Consider an architecture that isn't built using a strong domain model, and instead relies heavily on stored procedures. That might be OK, or it might not be OK. You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures, right? So an architecture is some reasonable regularity about the structure of the system, the way the team goes about building its software, and how the software responds and adapts to its own environment. How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.
The system architecture determines how hard or easy it is to implement a given feature. Good architectures are those in which it is considered easy to create the features desired. In that the way to judge whether an architecture is good is whether the architecture is good for the purposes to which it is applied.
The definition of goodness has to be related to fitness for purpose. Is this glove good? I don't know. What are you doing with the glove? Are you throwing snowballs, cooking barbeques, or playing golf? There's a set of changes that are going to occur to a software system over time. Probably the utilitarian or most useful definition of goodness is the answer to this question: are the changes that will keep this system successful in this domain in this product line relatively easy? If they are, then it's probably a good architecture.
3. 架構的背后
為了實現架構的目標涉及到以下三個方面：技術，組織和過程。這里舉例說明。
1) 技術對開發效率和運行性能，以及組織和過程的影響。
案例A.映射的問題。公司產品的一個重要需求是根據客戶輸入，映射到PDF文件上。技術上整體實現需要四個步驟：在PDF文件上畫好所有的數據域，通過讀入一個XML映射文件，獲得運行數據并生成FDF，合并FDF和PDF生成目標文件。后兩步工作都由代碼自動化了，因而實現的主要工作在于前兩步。
在第一個實現版本里，XML映射文件的DTD太簡單，致使一個xml文件至少在4000行左右，同時xml文件太verbose了。這樣的結果直接導致運行系統在峰值時，由于XML消耗了大量內存，1G的內存根本吃不消;同時對XML解析執行使用了CPU的大量時間;導致開發人員需要做大量的工作，開發效率降低了，通常需要盡一周才能完成一個xml文件，員工都不愿意做;也導致開發過程的漫長， 開發部門對于BA部門和ST部門的要求反應變的緩慢。
文章來源于領測軟件測試網 http://www.kjueaiud.com/