對我而言，如何學習「系統架構」一直是乙個大難題。我把程式設計學習分為了三個境界：
只有乙個解決方案
不止乙個解決方案
最好的解決方案
當我們最開始學習程式設計時，只要能把問題解決掉，把功能實現出來，就沾沾自喜；如果實現的功能夠華麗夠出彩，就更是「拽」得不行了。但當我們的視野更加的開闊，我們就會慢慢發現，很多問題，其實並不有乙個解決方案，這麼做也行，那樣做也不錯，所以問題隨之而來，哪乙個才是最好的呢？即使只針對乙個很小很具體的問題，不同的人從不同的視角出發，都會給出不同的答案，更何況「系統架構」這樣乙個如此複雜、如此主觀的問題？所以我記得一本講架構的書（如果知道原文出處，敬請告知！）裡說過：講架構是很難舉例的，例子太簡單，不足以體現架構的作用；例子太複雜，將不得不把大量的篇幅花在講解業務邏輯上，而且當讀者已經被複雜的業務搞得暈頭轉向之後，已經很難再集中精力理解架構的魅力了。
在我這些年的工作和學習中，我也看過幾本架構方面被公認為「經典」的書籍，但自覺收穫不大，可能就是基於上面的原因。「紙上得來終覺淺，絕知此事要躬行」，所以我乾脆自己動手，鼓搞出幾個專案再說，在實踐中學習成長。目前為止，我已經開發了兩個專案：
最初我曾經打算，將這個部落格系列和專案程序同步，專案做到**，部落格就寫到**。但鑑於自己的水平有限，專案進行途中，屢次大改，所以出於對讀者負責的態度，暫停了部落格的發布，希望能在架構稍加穩定之後再發布部落格。我想，現在應該是乙個比較恰當的時機了——雖然架構還遠算不上完美，但至少已經趨於穩定；而且回頭來看，讓我收穫良多的，正是那些輾轉反側的考量、對系統「千錘百鍊」的敲打、如切如磋的雕琢，而不是乙個系統最終的「成品快照」。所以我想即使系統再有更新和改進，和大家一起分享其中的經驗教訓所思所得，也是未嘗不是一件幸事——痛苦讓我們深刻。
專案是我利用業務時間自行開發的，但不會只是乙個玩具。我的目標是通過這個專案的運作，實現二次成功創業，所以專案會一直開發下去，我也會和。
我會開放所有的專案源**，希望各位同學能夠更積極的參與其中，因為：
我並不是專家，甚至連高手都算不上，只是乙個系統架構的菜鳥（我的經歷可參考：程式設計師30過後）。至今為止，我還沒有過乙個完整的專案開發經驗，所以你不要相信我，我自己都不相信我自己——我還希望能從大家那裡得到一些啟發和幫助呢！
正如我在《我學習設計模式的一些所想所得》中所說，實踐是掌握軟體工程技術的最根本最重要手段。再深入淺出的技術文章都不可能像暢銷書一樣通俗易懂，你必須真正的深入其中，自己去思考體會，才能得到你自己的東西。
我會跟隨專案的進度，一步一步的分析講解我的思路和方案。所以，你的建議和幫助，很可能進一步的完善和優化這個專案喲！
目錄：架構之路--實戰專案記錄（一） 概述
架構之路--實戰專案記錄（二） 忘記資料庫 開始抽象
專案記錄 架構
今天，專案負責人召集大家開會，要修改我們前面做的設計，並給我們展示了他這2天進行的架構設計。另外兩位同事都有自己的意見，一是覺得要需求牽引，不支援前期的可能是過度也可能是錯誤的設計 二是要修改的 量過大，前面的工作大部分都要重來。我看了 展示後，有這樣的感覺 1 架構設計得很好 2 寫得很好 3 擔...
ANDROID專案重構之路 架構篇
寫於2015 06 05 我將專案分為了四個層級 模型層 介面層 核心層 介面層。模型層定義了所有的模型 介面層封裝了伺服器提供的api 核心層處理所有業務邏輯 介面層就處理介面的展示。幾個層級之間的關係如下圖所示 這裡寫描述 介面層封裝了網路底層的api，並提供給核心層呼叫。剛開始，為了簡單，該層...
Android專案重構之路 架構篇
我將專案分為了四個層級 模型層 介面層 核心層 介面層。模型層定義了所有的模型 介面層封裝了伺服器提供的api 核心層處理所有業務邏輯 介面層就處理介面的展示。幾個層級之間的關係如下圖所示 下面展開說明具體的每個層次 介面層封裝了網路底層的api，並提供給核心層呼叫。剛開始，為了簡單，該層的核心類我...