有點像標題黨，其實沒這麼恐怖。但對於做構架設計，我想很多人也有這樣的感受，在過程中有時就像進入煉獄，備受煎熬。而當把所面對的問題基本梳理清楚，或者架構基本完成時，有如走出了煉獄。要讓框架成為使用者很好的幫手，對於開發者來說，進出煉獄其實也是正常的。本文主要聊一些框架設計的原則，這就當成原則的第0條。
0、設計者的煉獄：
從使用者考慮，這是需要的，更多理由見上。
1、開放的，而不是封閉的：
框架是為使用者鋪寬一條路，而不是把使用者帶向一條窄路。在設計中遵循和融合各種標準，堅持開放的原則，是一種對使用者負責的態度。
2、整合而不是空中閣樓：
做構架不是閉門造車，框架設計其實是約束和融合的過程，構架最終目的是提供簡便。約束和分層讓系統變得簡單、有序，而融合同樣為系統提供了方便。
3、要有特點、有所特長：
框架是提供給使用者使用的，使用者選用框架，不單是因為功能，也是因為框架的特點。
4、要反映趨勢，而不是反趨勢：
做框架最難的在於對趨勢的把握，但這也是做框架最需要的。做框架不但要滿足現在業務需要，也要盡量預見到以後的一些基本需要，誰也不會希望是滿足以前的業務需要，即使這樣的要求一時看起來有些迫切。
5、要清潔、層次清楚、易於調整、易於擴充套件：
框架本身也不是一層不變的，設計完成只是乙個台階，需要不斷演進，所以不能把框架設計成乙個怪物，難於調整，清晰的層次和協議是需要的。框架的擴充套件在於使用者，而不在於設計者，這也是框架生命力所在。
6、協同原則：
現在的需求越來越複雜，單兵作戰已經很難做好一件事，而框架則應該提供協同開發的平台，提供解決問題的整套思路。
「需求入架構出」 關於架構設計的思考
軟體的架構設計的重要性就不多說了，採用錯誤的架構，無論軟體的功能多麼豐富，使用者介面多麼友好，都逃脫不了失敗的命運，就像一棟用竹子搭起來的大樓骨架，外立面不管做的多漂亮，都注定在風雨中飄搖。關於如何設計架構，有很多大師都做了深入的闡述，我在這裡就不再贅述，本文是我在多年的軟體研發中對架構設計的一些思...
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...
關於架構設計文件
很多人覺得架構文件沒有什麼寫的，或者說不知道要怎麼寫。其實我覺得這是因為自己對架構 或者對業務需求並不是那麼理解。如果真的理解了，再來寫這個文件，會發現真的有很多可以寫的地方。因為你在明白架構設計文件的目的 作用後，就知道這個東西不僅僅是拿來糊弄公司的，而是真的有指導意義的。首先要理解架構設計文件的...