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