有不少web專案經理同時兼任架構師的角色，包括我。
一般而言，我們指的架構，多指技術上的架構，硬體上的架構。
最近在豆瓣上看書評時，看到乙個概念：web專案，從不同的角度，可以分為三種架構：業務架構，資訊架構，技術架構。
業務架構以賺錢為中心，資訊架構以使用者為中心，技術架構以穩定為中心。架構的目標，是要建立乙個堅實的、經得起時間考驗的體系。過度強調哪一方，都會不同程度的對整體造成影響。
最近做專案總結的時候想起該理論，覺得這樣的思路很好，套用在專案的需求分析和系統設計階段，可以讓分析的目的更明確，更有效。
在專案初期需求分析階段，如果從上述三個架構入手，把思路和疑問理清之後，整個專案的脈絡就基本清晰了：
業務架構：**的主要用途是什麼？**如何盈利，如果非盈利性**，**的價值是什麼？**所屬的行業？**的使用者是哪些人群？......
**的業務架構是**存在的價值，決定**的功能，流程，樣式，頁面設計，因此充分理解業務架構是需求分析的基本工作。其涉及的文件（或最終形成的文件）有：頁面遷移圖，畫面詳細設計書等。
資訊架構：即**的資料組織。各種資料之間的依賴，從屬等關係系。資料的關係，規模，要相應的採用不同的資訊架構。其涉及的文件（或最終形成的文件）有：資料字典。
技術架構：即我們最常說的架構，含程式的架構，伺服器的架構。需求分析階段，對技術架構就一定的輪廓，比如要涉及到什麼技術，需要多少伺服器，有個基本的判斷是必須的。因為必須考慮技術上和成本上的可行性。而到系統分析階段，技術架構就應該具體化，文件化了。其涉及的文件（或最終形成的文件）有：模組設計書，系統設計書，top risk list（風險列表）等等。
隨著經驗的增長，該文會陸續完善~
從不同架構的角度進行web專案的需求分析和系統設計
有不少web專案經理同時兼任架構師的角色，包括我。一般而言，我們指的架構，多指技術上的架構，硬體上的架構。最近在豆瓣上看書評時，看到乙個概念 web專案，從不同的角度，可以分為三種架構 業務架構，資訊架構，技術架構。業務架構以賺錢為中心，資訊架構以使用者為中心，技術架構以穩定為中心。架構的目標，是要...
用架構思維從不同角度講述效能測試的要點
這裡說的架構，指的是在大型 中常用的分布式架構模式 如果橫向來分割我們的系統，一般我們把它分為應用層，服務層，資料層 如果縱向來分割我們的系統，一般我們是按照模組來劃分 在提供服務的時候，我們會分布式的架構我們的系統，因為分布式可以給我們帶來如下的好處 cpu數量增多，處理速度加快 內存在變大，資料...
值得從不同角度思考的反直覺問題
1 三門問題monty hall problem mueser 和 granberg 透過釐清細節，以及對主持人的行為加上明確的介定，提出了對這個問題的一種不含糊的陳述 轉換選擇可以增加參賽者拿到汽車的機會嗎？比如從概率論 貝葉斯推理 因果關係的角度分析。2 紅眼睛藍眼睛問題the blue eye...