1. 軟件架構(gòu)設(shè)計可以基于數(shù)據(jù)庫的模型設(shè)計也可以基于領(lǐng)域模型設(shè)計。對于業(yè)務(wù)系統(tǒng)來說，如果他的核心是數(shù)據(jù)處理和分析，而且數(shù)據(jù)量很大可以在架構(gòu)設(shè)計時采用基于數(shù)據(jù)庫建模的方式，對于一些中小型的應(yīng)系統(tǒng)一般習(xí)慣上是用領(lǐng)域驅(qū)動設(shè)計。
2.分層是軟件架構(gòu)的基本理論。任何軟件在邏輯上都可以分層，也可以適當(dāng)?shù)挠成涞轿锢韺哟紊希劣谠趺捶郑侄嗌賹樱灰值纫茨愕能浖I(lǐng)域（每個領(lǐng)域都有一些現(xiàn)成的架構(gòu)模式可以參考，所謂領(lǐng)域架構(gòu)），在拿到需求的時候我們習(xí)慣上進行水平和垂直的分割，其實分層技術(shù)也是一種基本的架構(gòu)模式。
3.BI商務(wù)智能，所謂的智能只不過是數(shù)據(jù)對業(yè)務(wù)的支持，通過ETL對數(shù)據(jù)的提取，篩選與清理等動作，集合數(shù)據(jù)支持，通過分析報表，OLAP等等提供商業(yè)決策支持，其實BI只是業(yè)務(wù)系統(tǒng)的一種，只是在原有業(yè)務(wù)管理系統(tǒng)的數(shù)據(jù)基礎(chǔ)上做了層分析模型，維度模型，更有利于商業(yè)決策罷了！
4.上班也已經(jīng)有兩三個星期了，每天都在坐公交車，從起點到終點，很無味。今天發(fā)現(xiàn)一個有趣的事，做公交這一途中發(fā)現(xiàn)了很多有特色的建筑，以前沒注意。其實我們軟件開發(fā)何嘗不是如此，需求就像路景考察，你不可能在一次起點到終點的過程就看到所有的建筑，你必須在公車的不同角度去看，很多建筑、路途景色會讓你眼前一亮。需求在起初的討論中是很難澄清的，除非你是非常小的系統(tǒng)。必須在不斷的開發(fā)中去探索，去發(fā)現(xiàn)和變更，現(xiàn)在很多程序員抱怨因需求和設(shè)計的變化而修改程序。其實這種現(xiàn)象很正常。
5.有時候可能憑著自己的性格，有離職的想法。但，當(dāng)你靜下心來想想，很多因素組織了你的想法。其實應(yīng)該以一種平常心去面對發(fā)生了和將要發(fā)生的事。
6.五年前開始用 UML2.0，支持工具 ROSE 和 Together 之類的。但是常常令人思考的是 UML 在項目中真的起到指導(dǎo)作用了嗎？未必，筆者做的很多項目都是前期畫畫，后期拋棄。結(jié)果前期花費了很多時間拖延了項目的進度，而且在后期維護階段，這些所謂的圖也沒有為后來者做什么貢獻。就是我所在的H公司，在這方面也不是很理想，或者說是一團亂麻。我想一個很重要的原因就是很多人會用UML，熟悉幾個工具，但UML的精髓并沒學(xué)到。還有就是在項目組中沒有一個體系結(jié)構(gòu)師做這方面的工作，你可以說這是中國的大環(huán)境。不盡然，一直以來我個人都倡導(dǎo)體系架構(gòu)。我們都知道 AP---適合小型項目、精英團隊的開發(fā)過程，在體系架構(gòu)方面沒有嚴格的要求，所以不適合大型，團隊分散的項目。前一段時間也思考了這個問題，寫了篇論文 <<敏捷與架構(gòu)對齊>>，下面我們還是認認真真看看UML的基本知識吧，為新手也為老手，有興趣的可以看看，總結(jié)的還是可以的。有啥問題歡迎討論。
7.項目客戶端完全采用 Ext 框架，表示層沒有 HTML, JSP 之類的東東，只有 CSS和JS。Ext 是個很好的東西，也有一些 bug，不過他更新的很快，也有很多示例系統(tǒng)和組件。在構(gòu)建前端表示的時候可以在很短的時間內(nèi)作出很炫的效果，真的是令你眼前一亮。和后端服務(wù)交互完全是基于 HTTP 協(xié)議的 JSON 對象字符串，可能有的項目中這是一個折中的選擇。不過我們現(xiàn)在這么做確實使服務(wù)端和前臺表示端完全分離了，結(jié)構(gòu)很清晰，而且也有明顯的效果。對于后臺開發(fā)也是嚴格遵守分層概念，符合正交體系結(jié)構(gòu)的設(shè)計概念，基于線索的開發(fā)模式和分工策略。在體系結(jié)構(gòu)方面有一清晰的架構(gòu)視圖，反映多中關(guān)注。目前這個項目已經(jīng)接近尾聲。第一個小版本要發(fā)布了，期待。
8.源代碼就是設(shè)計，似乎是老生常談，但是很多人還是轉(zhuǎn)不過彎來，俗話說：“重構(gòu)一段代碼很容易，但重構(gòu)一個人的思想是很難的”。
9.對于一個分層的系統(tǒng)來說，代碼構(gòu)造方式有兩種：一種是自頂向下的構(gòu)造方法；一種是自底向上的構(gòu)造方法。這兩種構(gòu)造方法都來源于分析，也就是說分析也有兩種：一種自頂向下的分析；一種自底向上的分析。這兩種分析都源于系統(tǒng)的邏輯層次性（如系統(tǒng)的層次理論，上層下層的關(guān)系（一種分析和分解關(guān)系）），系統(tǒng)分層源于復(fù)雜問題的分解，也就是所說的簡單化問題空間以及問題歸約方法論。這種分解方式源自于人們認識自然和改造自然的一個學(xué)習(xí)過程（是人們改造自然、認識自然的經(jīng)驗在系統(tǒng)開發(fā)中的一種體現(xiàn)）
10. 支撐系統(tǒng)參考架構(gòu)
支撐系統(tǒng)架構(gòu)
|
————————————
| |
靜態(tài)架構(gòu) 動態(tài)架構(gòu)
| |
—————————— 業(yè)務(wù)場景架構(gòu)
| |
應(yīng)用軟件架構(gòu) 視圖架構(gòu)
|
————————————————————
| | | |
功能架構(gòu) 技術(shù)架構(gòu) 信息架構(gòu) 流程架構(gòu)
本博客為學(xué)習(xí)交流用，凡未注明引用的均為本人作品，轉(zhuǎn)載請注明出處，如有版權(quán)問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學(xué)習(xí)進步。