在進行設計原則的討論之前，首先要明確乙個事實:
在乙個軟體專案團隊中，在討論專案設計的時候，每個人都會有自己的設計理念。這些設計理念一般都跟每個人的成長經歷有關係。跟使用者密切接觸的人員，比如：產品經理，售前經理等，在設計乙個系統的時候更考慮整個系統如何設計才能更加方便使用者，更加貼合使用者的業務流程，才能解決使用者面臨的問題。而研發體系的人員，比如：系統架構師，開發經理，一般更加側重於系統架構如何高效執行，如何減少**工作量，如何減少系統的複雜度。
因此在乙個專案團隊中，經常會出現這樣一種情況：如果乙個專案設計的決策權在產品經理時，在開發人員真正開發**的時候，會抱怨產品經理設計的功能沒法實現，或者實現的難度太大了，甚至對整個架構造成巨大的破壞。尤其是在專案後期增加需求的時候。
而如果乙個系統完全由開發經理或者系統架構師來實現，可能會設計出乙個非常方便開發人員使用的架構，但是在滿足開發經理的各種需求的時候，因為架構的限制可能沒法實現，這個時候產品經理或者售前經理又會說，這是什麼破系統，什麼都實現不了。
這個問題的核心原因在於：產品經理（售前）更加熟悉業務，不關係技術實現難度的問題，更多的是從業務角度來設計系統。而開發經理（架構師）更多的是從技術角度來設計系統。以模組化為例，對設計由一定經驗的人員都知道，設計之初的模組化的劃分至關重要。但是真正設計系統的時候，產品經理更多的是考慮使用者業務模組的概念，而架構師在設計的時候更多考慮技術模組，**復用等模組概念。
那如何才能設計出更加完善的系統架構呢？在設計系統架構的時候應該遵循什麼原則呢？
我的意見是：所有的設計不能由某個人來決定是否合理，應該遵循一種大家認可的設計原則。評價設計是否合理應該從多個角度來進行評判，不能一直站在乙個角度來評判設計的優缺點。比如不能站在業務架構的角度來批評技術架構設計的不合理。也不能站在技術架構的角度來批評業務架構不合理。應該讓大家從兩個方面都要有一定的妥協，相容兩個甚至多個層面。
在真正開始介紹公共資訊平台的設計原則之前，先說兩種通用的設計思路：
1. 自上而下設計：指的是從根元素進行分析，一步步進行分層設計。
2. 自下而上設計：指羅列能夠確認的底層模組，對模組進行彙總總結，一步步進行總結層次，最終形成最上層。
分別考慮兩個設計模式的優缺點：
1. 自上而下設計：
優點：l 可以從上層把控整個系統的層次結構。不會出現層次混亂的問題。
l 前期層次較少時，層次明確，設計簡單。有利於前期工作開展。
l 給領導更好的進行匯報。
l 可以更好的進行組織安排，比如把不同的層次分給不同的人員來進行設計。但總體架構不收影響。
l 某個模組設計完成之後，可以提前進入開發階段。
缺點：l 不利於風險的識別。子節點的風險尤其是影響整個系統的風險在一開始無法識別出來，積極應對，容易總成專案的重大問題。比如成本增加，進度拖延。
l 不利於整體架構設計，自上而下設計，一開始的分層依據不夠，容易在後續分層時對上層架構繼續大規模的調整。
l 層次變多之後，層次之間的關係複雜度變高，設計難度加大。甚至出現自相矛盾的設計。
典型應用場景：
售前人員在進行系統方案設計時採用的典型方法。可以根據使用者的要求，按照使用者目的形成業務模組，設計出完全符合使用者業務的模型。
2. 自下而上設計：
優點：l 可以充分考慮各階段的風險問題，將風險提前羅列，提前準備應對措施，減少專案失敗的風險。
l 設計上因為考慮的更加全面，幾乎不會出現重大的返工問題。
l 設計越往後難度越小。
缺點：l 前期理清底層單元模組困難，容易造成邏輯混亂，設計難度大，不利於前期工作開展。
l 由於設計的特性導致，必須所有的設計完成之後，才能進入開發。
l 工作組織不好安排，更多的是依賴於經驗豐富的人員繼續風險識別。
l 前期工作瑣碎，不容易見成果，因此不容易跟領導進行匯報。
典型應用場景：
技術框架或者小型系統的系統設計，在做乙個小型的系統時，由於結構比較清楚，因此可以考慮各個方面的影響因素，設計完成之後，功能比較穩定。尤其是技術框架的設計，一定會充分考慮各種細節之後，才會進行整體的開發。
實際工作中一般不會直接使用其中的一種，比如乙個資訊系統的開發，一般是由開發經理或者架構師將所有可能的風險或者問題提前羅列進行各種的風險評估，計畫審定，然後按照自下而上的方式進行文件編寫，規劃制定，方便領導審批，工作組織，計畫制定。
對應到我們的公共資訊平台，我們也建議採用複合型的架構模式。
以自上而下為主，但是充分考慮各個階段的問題。通過各個角度的架構來驗證系統是否合理。
也就是說：
1. 由於現在缺少使用者明確的需求確認，只有幾分簡單的指南和國標，因此在設計時首先保證大的框架不錯，從上而下設計。以自上而下為「綱「，為設計主線。
2. 在進行設計時，考慮到工期的問題，建議在整個設計的過程中，充分考慮各個階段的問題和風險，隨時將能想到的問題和風險進行確定。作為設計的「頁子」，作為設計的「副本」。
a) 將大家理解不同的術語和概念，提前統一。
b) 將大家提出的問題，提前確認。
c) 將大家提出的風險，提前進行預防和規避。
3. 詳細的問題列表和風險列表，有利於制定更加完善的技術架構和開發計畫。保證產品正常的開發進度。
4. 從多個角度，使用者問題角度，業務流程角度，技術架構角度等來對架構進行描述整理，以及驗證，保證架構的合理性。不能只考慮業務架構的合理性不管技術實現難度，也不能只考慮技術架構的方便性，不考慮業務實際情況（專門文件介紹）。
大型資料庫設計原則
摘要 大型資料庫相比較於以前檔案型資料庫有著其眾多的優點，也是當今 mis系統開發的的首選產品。但是，資料庫模型的設計合理會極大地影響到 mis系統使用效能。本 根據作者多年從事資料庫設計的一些經驗，闡述了資料庫設計時的一些準則。隨著市場競爭的加劇和資訊社會需求的發展，人們對資訊的處理 獲取 發布 ...
關於Topic設計的思考
topic 的數量隨著業務的增長逐漸增多，如何正確的設計 topic 成了當務之急。在這篇文章中，將重點討論mqtt 主題和最佳實踐。topic是utf 8字串，broker用於過濾客戶端的訊息，乙個topic由乙個或多個主題層組成，每個主題級別用 分割。home floor room sensor...
關於Ajaxian JSF的設計原則
目前網上大大小小的ajax framework已經計算不清了，但是基本實現形式都是，通過js響應客戶端瀏覽器的某個事件，然後呼叫乙個js函式，在此函式中使用servicecall之類的方法。接下來的處理就見仁見智了，通常是兩種 1 返回的resultobject，可能是xml,html，或者其他自定...