1.架構,首先是乙個骨架的概念,所以它包含的東西應該是泛而概括的東西,它應該是乙個對實現的總體勾勒描述,不應該是乙個具體的實現.架構應該為後續的實現提供思想指導。
其次這個骨架應該描述各個部分(子系統/異構系統/構件)之間的介面定義,這些定義提供實現時的總體規範及系統佈署時的描述規範.
最後這個骨架應該是搭建起來的技術上驗證通過的：穩定的、容變的、可執行的系統。一般地乙個架架構是為乙個具體的系統設計的。
2.框架 首先也是乙個骨架的概念,但它是面向某一技術領域(側重點)或業務領域--更多是技術領域提供的乙個具體實現,這個具體不是象專案開發那樣對業務需求的具體化實現，它是對一種技術領域或業務領域的具體化實現。在應用某一框架做乙個具體的實現時（比果開發乙個具體的業務系統），我們需要參照框架的具體實現規範,這個實現規範為應該做到了最大化的重用性與解決某一技術問題的特殊性。 網上搜一下，現在開源框架多了，大多是解決某一技術領域而提出的。但解決業務領域問題的框架由於商業原因大多不開源的（看來開源在不涉及利益時是可以，反之而不行，再看看ms在做開源上有多難，又開源了些什麼東西你就明白了）
3.模式 為解決某相似性問題而提供的通用解決方案(一類大致相同的問題),這些問題具有相似性，並且解決方法也具有想似性，自從模式被「建築學界」使用之後，這種解決相似性問題的通用解決方法被歸類、記錄,隨後它們被稱作為模式被應用。
我想說的是，即然架構是為乙個系統設計，那麼為設計相類的系統(相似的系統是需要解決的問題，那麼通用的架構是解決方案)應該可以參照某一種模式；即然框架是為解決某一技術或領域問題而生，那麼一類相似的技術問題也應解決它們的方案--模式。所以模式描述與解決問題的更高階抽象，架構設計與框架設計時離不開模式(儘管你沒有明確的寫出你應用了哪個模式，或許它早已默化在你的腦海裡了）
設計模式 總體認識
前言 如果把進行專案研發比作成數學題的計算的話，那麼程式設計就像是計算，而設計模式的使用就像是化簡！不同的題可能適合不同的化簡方式，通過化簡，題目會變得更加容易而正確率也會大大提高。由此可見設計模式的重要性。但是我們千萬不能由此而忽略了程式設計的重要性！比如，一道題過來，如果你的計算能力不夠，你就是...
對軟體架構的認識
目前，我們已經是大三的學生了，但是我對軟體架構的具體內涵還不是很清楚。對於 什麼是架構？的問題還模稜兩可，所以我今天閱讀了 架構漫談 系列的部落格，讀完以後對於軟體架構有了更深層次的理解。架構 一詞最早是跟隨著建築出現的，而不是由軟體工程專業產生的。為什麼會產生架構呢？在部落格裡作者根據乙個通俗易懂...
對設計模式 Adapter模式的認識
人在生活中有時擔任一種角色，有時候要擔任好幾種。比如做軟體開發，公司大點的，有開發人員也有測試人員分工細化 明確，公司小的，為了節約成本，開發人員既開發又測試。public inte ce itestengineer public class testengineer implements ites...