+++++++++++++++++++
2016年11月23日 補充
後續行動：倡議：我們“一起幫”
+++++++++++++++++
終於決心再一次開始這個系列的部落格了。之所以說再一次，是因為我之前曾經試著寫過這樣一個系列，但中途卻不得已停了下來。我總記得“之前”就是一兩年前，檢視部落格後才發現原來那居然已經是三年前了！不禁感慨歲月如梭，時間都去哪兒了？大概我轉行做軟體開發的時候，我的小女兒也開始孕育。如今，她已經是亭亭玉立的一個小姑娘，天真浪漫；而我這六七年的收穫呢？
我學計算機學開發，目的很明確，就是奔著“架構”來的。當然，最初我不知道這個名詞，我以為我就是去學“做網站”的。什麼時候能夠學會？最開始我以為三個月應該夠了，然後延期到六個月，再延期到一年、兩年……直到現在。在這個過程中， 我算是深刻的體會到“學無止境”，或者“學得越多越覺無知”是什麼意思。
三年前覺得自己應該有資格可以顯擺一下了，但到中途卻越來越迷茫困惑，所以不得已再去摸索實踐。沒想到，這一摸索實踐，又是三年過去了！三年過去了，實事求是的說，我比三年前更心虛了：一些以前深信不疑的觀點變得猶豫起來，一些從未有過的想法時不時的蹦了出來，新的技術猛烈的衝擊著舊有的體系……我會不會還是誤人子弟而已？
思前想後，我還是下定決心，重新開始這個系列。因為我百分百的相信，即使再過三十年，我也不會成為一個完美的架構師擁有一個完美的架構。所以，沒有必要等到“完美”，也不可能有真正的“完美”。就在現在吧，把我的所學所思所得都展示出來，和大家一起交流碰撞，於人於己，都善莫大焉。
架構太難了！準確的說，是把架構做好太難了。
我曾經把技能分為兩類：會和好。比如：“我會寫字”和“我字寫得好”，這完全是兩種不同的境界。“會”其實很容易，而“好”則很難。而很不幸，架構就是一個專注於“好”而不是“會”的技能領域。任何一個系統，無論大小好壞，都有架構；所以只要能開發出一個系統，就已經“會”架構了。但我們的關注點，顯然在於如何進行“好”的架構。這個問題如此難以問答，以至於我還沒有發現過一本專門論述該問題的書籍。被奉為經典的《企業應用架構模式》更像是一個架構彙編，告訴我們有哪些哪些架構模式而已（當然，我們不能否定它的巨大價值）；其他類似的書籍實際上也未能給出明確的答案。在網上，相關的問題通常最後演變成一場“口水戰”，讓人眼花繚亂最終不知該何去何從。
我實在查不到這段話的出處，但大意是：為什麼講解架構這麼難（比如為什麼要分層要抽象要封裝）？因為如果沒有一個足夠複雜邏輯的例子，就無法展示這樣做的好處；但如果給出一個足夠複雜邏輯的例子，就不得不花費大量的篇幅首先講明這一堆複雜的邏輯，而讀者在暈頭轉腦的理解這些複雜業務邏輯之後，很難再有精力來思考架構的技術問題本身。
所以我最後決定採用這種方式來學習：自己去搭建一個有足夠複雜業務邏輯的系統，在實踐中一步步的學習領會各種架構知識。這是一個很笨的方法，但確是一個很有效的方法。伴隨著系統的不斷開發完善，書上的很多說法得以印證，我之前的很多想法得以改變。每寫一行程式碼，我都能感覺到我的一分進步！軟體開發是一門實踐藝術，坐而論道往往不如身體力行，正應了那句話，“紙上得來終覺淺，絕知此事要躬行”。
所以，接下來我將以兩個目前仍在開發的專案（詳見：英雄帖：開源專案招募英才）為例，一步一步的講解，如何通過領域驅動和測試驅動，進行敏捷開發，構建一個物件導向的B/S系統。