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. 支撐系統參考架構
支撐系統架構
|
————————————
| |
靜态架構 動态架構
—————————— 業務場景架構
| |
應用軟體架構 視圖架構
|
————————————————————
| | | |
功能架構 技術架構 資訊架構 流程架構
![mybatis_入門程式Mybatis入門[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)