+++++++++++++++++++
2016年11月23日 补充
后续行动：倡议：我们“一起帮”
+++++++++++++++++
终于决心再一次开始这个系列的博客了。之所以说再一次，是因为我之前曾经试着写过这样一个系列，但中途却不得已停了下来。我总记得“之前”就是一两年前，查看博客后才发现原来那居然已经是三年前了！不禁感慨岁月如梭，时间都去哪儿了？大概我转行做软件开发的时候，我的小女儿也开始孕育。如今，她已经是亭亭玉立的一个小姑娘，天真浪漫；而我这六七年的收获呢？
我学计算机学开发，目的很明确，就是奔着“架构”来的。当然，最初我不知道这个名词，我以为我就是去学“做网站”的。什么时候能够学会？最开始我以为三个月应该够了，然后延期到六个月，再延期到一年、两年……直到现在。在这个过程中， 我算是深刻的体会到“学无止境”，或者“学得越多越觉无知”是什么意思。
三年前觉得自己应该有资格可以显摆一下了，但到中途却越来越迷茫困惑，所以不得已再去摸索实践。没想到，这一摸索实践，又是三年过去了！三年过去了，实事求是的说，我比三年前更心虚了：一些以前深信不疑的观点变得犹豫起来，一些从未有过的想法时不时的蹦了出来，新的技术猛烈的冲击着旧有的体系……我会不会还是误人子弟而已？
思前想后，我还是下定决心，重新开始这个系列。因为我百分百的相信，即使再过三十年，我也不会成为一个完美的架构师拥有一个完美的架构。所以，没有必要等到“完美”，也不可能有真正的“完美”。就在现在吧，把我的所学所思所得都展示出来，和大家一起交流碰撞，于人于己，都善莫大焉。
架构太难了！准确的说，是把架构做好太难了。
我曾经把技能分为两类：会和好。比如：“我会写字”和“我字写得好”，这完全是两种不同的境界。“会”其实很容易，而“好”则很难。而很不幸，架构就是一个专注于“好”而不是“会”的技能领域。任何一个系统，无论大小好坏，都有架构；所以只要能开发出一个系统，就已经“会”架构了。但我们的关注点，显然在于如何进行“好”的架构。这个问题如此难以问答，以至于我还没有发现过一本专门论述该问题的书籍。被奉为经典的《企业应用架构模式》更像是一个架构汇编，告诉我们有哪些哪些架构模式而已（当然，我们不能否定它的巨大价值）；其他类似的书籍实际上也未能给出明确的答案。在网上，相关的问题通常最后演变成一场“口水战”，让人眼花缭乱最终不知该何去何从。
我实在查不到这段话的出处，但大意是：为什么讲解架构这么难（比如为什么要分层要抽象要封装）？因为如果没有一个足够复杂逻辑的例子，就无法展示这样做的好处；但如果给出一个足够复杂逻辑的例子，就不得不花费大量的篇幅首先讲明这一堆复杂的逻辑，而读者在晕头转脑的理解这些复杂业务逻辑之后，很难再有精力来思考架构的技术问题本身。
所以我最后决定采用这种方式来学习：自己去搭建一个有足够复杂业务逻辑的系统，在实践中一步步的学习领会各种架构知识。这是一个很笨的方法，但确是一个很有效的方法。伴随着系统的不断开发完善，书上的很多说法得以印证，我之前的很多想法得以改变。每写一行代码，我都能感觉到我的一分进步！软件开发是一门实践艺术，坐而论道往往不如身体力行，正应了那句话，“纸上得来终觉浅，绝知此事要躬行”。
所以，接下来我将以两个目前仍在开发的项目（详见：英雄帖：开源项目招募英才）为例，一步一步的讲解，如何通过领域驱动和测试驱动，进行敏捷开发，构建一个面向对象的B/S系统。
