一、什么是架構(gòu)
1. 和架構(gòu)相關(guān)的幾個問題域
架構(gòu)需要解決的非業(yè)務(wù)問題域包括如下：
A 系統(tǒng)目標：系統(tǒng)性能，穩(wěn)定性.
B.項目目標：開發(fā)成本，質(zhì)量
C.項目過程：需求的不確定性和開發(fā)過程的團隊協(xié)作性
不同的問題域，解決之道也不相同！而同一問題域的不同層次的要求，解決之道也不盡相同。
2. 什么是架構(gòu)
架構(gòu)到底是啥，愚以為下面的這段英文描述的很清楚。
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. 架構(gòu)的背后
為了實現(xiàn)架構(gòu)的目標涉及到以下三個方面：技術(shù)，組織和過程。這里舉例說明。
1) 技術(shù)對開發(fā)效率和運行性能，以及組織和過程的影響。
案例A．映射的問題。公司產(chǎn)品的一個重要需求是根據(jù)客戶輸入，映射到PDF文件上。技術(shù)上整體實現(xiàn)需要四個步驟：在PDF文件上畫好所有的數(shù)據(jù)域，通過讀入一個XML映射文件，獲得運行數(shù)據(jù)并生成FDF，合并FDF和PDF生成目標文件。后兩步工作都由代碼自動化了，因而實現(xiàn)的主要工作在于前兩步。
在第一個實現(xiàn)版本里，XML映射文件的DTD太簡單，致使一個xml文件至少在4000行左右，同時xml文件太verbose了。這樣的結(jié)果直接導(dǎo)致運行系統(tǒng)在峰值時，由于XML消耗了大量內(nèi)存，1G的內(nèi)存根本吃不消；同時對XML解析執(zhí)行使用了CPU的大量時間；導(dǎo)致開發(fā)人員需要做大量的工作，開發(fā)效率降低了，通常需要盡一周才能完成一個xml文件，員工都不愿意做；也導(dǎo)致開發(fā)過程的漫長， 開發(fā)部門對于BA部門和ST部門的要求反應(yīng)變的緩慢。
在第二個版本的實現(xiàn)中，重新實現(xiàn)了DTD，加入了大量的關(guān)鍵字同時也消除了verbose，大量的縮小了XML大小，從4000多行減低到900多行。不僅減低了內(nèi)存使用，提高執(zhí)行效率；也提高了開發(fā)效率，基本只要一天就可以完成一個映射文件。同時對BA部門和ST部門的反應(yīng)也快了。
案例B：腳本的問題。產(chǎn)品在web層提供了腳本支持，出于方便開發(fā)的目的。但是沒有對腳本的環(huán)境限制，腳本可以做系統(tǒng)程序的大部分工作。導(dǎo)致開發(fā)人員偷懶，在web層混入了大量業(yè)務(wù)邏輯代碼。最終造成業(yè)務(wù)邏輯分散而不可控制。
2) 組織結(jié)構(gòu)對技術(shù)，開發(fā)效率和應(yīng)變能力的影響。
案例A.部門的分工問題。開發(fā)部門根據(jù)不同的職責(zé)，分成A，B和C等數(shù)個小組。大部分開發(fā)中互不相干。但也有時候，需要跨組的支持，比如B要實現(xiàn)某個需求，需要A在一定條件在記錄一個或多個信息。因為每個開發(fā)人員各自負責(zé)一部分工作，導(dǎo)致跨組溝通的困難。同時由于整個開發(fā)部采取任務(wù)績效，有時間壓力，加上只是一個小的要求。于是在A人員的同意下，B人員直接在A代碼中寫入業(yè)務(wù)邏輯。每次都是這樣的小改動，不斷的發(fā)展后，代碼開發(fā)變凌亂。
案例B.開發(fā)的歷史問題，當某個開發(fā)人員寫下的代碼，有是問題的，接手開發(fā)人員由于文檔不全以及沒有測試用例，不愿意承擔變化的代價，選擇小修小補，這個小修小補有可能和有問題的代碼混雜，導(dǎo)致更大的代碼。
3) 過程對開發(fā)效率和應(yīng)變能力，以及組織的影響
案例A.過程的問題。開發(fā)部門的上下游部門BA部門和ST部門的合作關(guān)系。ST部門的績效考核,考核基于發(fā)現(xiàn)錯誤的數(shù)量，導(dǎo)致ST為了完成任務(wù)，提出一些非正常性要求。PM部門出于部門的方便通常提出一些實現(xiàn)難度比較大要求。開發(fā)部門本身又存在時間壓力，導(dǎo)致一些需求的實現(xiàn)本應(yīng)在低一層的代碼中實現(xiàn)的，卻在高層用蹩足的方式實現(xiàn)。
案例B.幫助系統(tǒng)的問題。幫助系統(tǒng)一開始采用一個個單獨分散的靜態(tài)頁面。出于性能的考慮和部門負責(zé)考慮。幫助系統(tǒng)不斷改進中，過程缺乏組織性，文件的命名規(guī)則隨意，存儲位置隨意，造成了管理的混亂。直接的后果是頁面的入口混亂和各自引用關(guān)系混亂。
在幫助系統(tǒng)的第二版，從靜態(tài)頁面轉(zhuǎn)成動態(tài)頁面。采取統(tǒng)一分類和命名規(guī)則，并統(tǒng)一了入口。同時采取分級管理引用關(guān)系，適度冗余。雖然減低了運行性能。但提高了開發(fā)效率和可維護性。
1. 和架構(gòu)相關(guān)的幾個問題域
架構(gòu)需要解決的非業(yè)務(wù)問題域包括如下：
A 系統(tǒng)目標：系統(tǒng)性能，穩(wěn)定性.
B.項目目標：開發(fā)成本，質(zhì)量
C.項目過程：需求的不確定性和開發(fā)過程的團隊協(xié)作性
不同的問題域，解決之道也不相同！而同一問題域的不同層次的要求，解決之道也不盡相同。
2. 什么是架構(gòu)
架構(gòu)到底是啥，愚以為下面的這段英文描述的很清楚。
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. 架構(gòu)的背后
為了實現(xiàn)架構(gòu)的目標涉及到以下三個方面：技術(shù)，組織和過程。這里舉例說明。
1) 技術(shù)對開發(fā)效率和運行性能，以及組織和過程的影響。
案例A．映射的問題。公司產(chǎn)品的一個重要需求是根據(jù)客戶輸入，映射到PDF文件上。技術(shù)上整體實現(xiàn)需要四個步驟：在PDF文件上畫好所有的數(shù)據(jù)域，通過讀入一個XML映射文件，獲得運行數(shù)據(jù)并生成FDF，合并FDF和PDF生成目標文件。后兩步工作都由代碼自動化了，因而實現(xiàn)的主要工作在于前兩步。
在第一個實現(xiàn)版本里，XML映射文件的DTD太簡單，致使一個xml文件至少在4000行左右，同時xml文件太verbose了。這樣的結(jié)果直接導(dǎo)致運行系統(tǒng)在峰值時，由于XML消耗了大量內(nèi)存，1G的內(nèi)存根本吃不消；同時對XML解析執(zhí)行使用了CPU的大量時間；導(dǎo)致開發(fā)人員需要做大量的工作，開發(fā)效率降低了，通常需要盡一周才能完成一個xml文件，員工都不愿意做；也導(dǎo)致開發(fā)過程的漫長， 開發(fā)部門對于BA部門和ST部門的要求反應(yīng)變的緩慢。
在第二個版本的實現(xiàn)中，重新實現(xiàn)了DTD，加入了大量的關(guān)鍵字同時也消除了verbose，大量的縮小了XML大小，從4000多行減低到900多行。不僅減低了內(nèi)存使用，提高執(zhí)行效率；也提高了開發(fā)效率，基本只要一天就可以完成一個映射文件。同時對BA部門和ST部門的反應(yīng)也快了。
案例B：腳本的問題。產(chǎn)品在web層提供了腳本支持，出于方便開發(fā)的目的。但是沒有對腳本的環(huán)境限制，腳本可以做系統(tǒng)程序的大部分工作。導(dǎo)致開發(fā)人員偷懶，在web層混入了大量業(yè)務(wù)邏輯代碼。最終造成業(yè)務(wù)邏輯分散而不可控制。
2) 組織結(jié)構(gòu)對技術(shù)，開發(fā)效率和應(yīng)變能力的影響。
案例A.部門的分工問題。開發(fā)部門根據(jù)不同的職責(zé)，分成A，B和C等數(shù)個小組。大部分開發(fā)中互不相干。但也有時候，需要跨組的支持，比如B要實現(xiàn)某個需求，需要A在一定條件在記錄一個或多個信息。因為每個開發(fā)人員各自負責(zé)一部分工作，導(dǎo)致跨組溝通的困難。同時由于整個開發(fā)部采取任務(wù)績效，有時間壓力，加上只是一個小的要求。于是在A人員的同意下，B人員直接在A代碼中寫入業(yè)務(wù)邏輯。每次都是這樣的小改動，不斷的發(fā)展后，代碼開發(fā)變凌亂。
案例B.開發(fā)的歷史問題，當某個開發(fā)人員寫下的代碼，有是問題的，接手開發(fā)人員由于文檔不全以及沒有測試用例，不愿意承擔變化的代價，選擇小修小補，這個小修小補有可能和有問題的代碼混雜，導(dǎo)致更大的代碼。
3) 過程對開發(fā)效率和應(yīng)變能力，以及組織的影響
案例A.過程的問題。開發(fā)部門的上下游部門BA部門和ST部門的合作關(guān)系。ST部門的績效考核,考核基于發(fā)現(xiàn)錯誤的數(shù)量，導(dǎo)致ST為了完成任務(wù)，提出一些非正常性要求。PM部門出于部門的方便通常提出一些實現(xiàn)難度比較大要求。開發(fā)部門本身又存在時間壓力，導(dǎo)致一些需求的實現(xiàn)本應(yīng)在低一層的代碼中實現(xiàn)的，卻在高層用蹩足的方式實現(xiàn)。
案例B.幫助系統(tǒng)的問題。幫助系統(tǒng)一開始采用一個個單獨分散的靜態(tài)頁面。出于性能的考慮和部門負責(zé)考慮。幫助系統(tǒng)不斷改進中，過程缺乏組織性，文件的命名規(guī)則隨意，存儲位置隨意，造成了管理的混亂。直接的后果是頁面的入口混亂和各自引用關(guān)系混亂。
在幫助系統(tǒng)的第二版，從靜態(tài)頁面轉(zhuǎn)成動態(tài)頁面。采取統(tǒng)一分類和命名規(guī)則，并統(tǒng)一了入口。同時采取分級管理引用關(guān)系，適度冗余。雖然減低了運行性能。但提高了開發(fā)效率和可維護性。