一直在思考架构是什么，概要设计是什么，详细设计是什么，都应该做到什么粒度。看大师的说法有时看着有理，却像在天上，在实际中总觉得落不了地，总结下自己的想法，就算不对，也要不断进步，向正确接近。

软件项目最后使用的只有在跑的代码，说白了代码好才是真的好。架构，及概设，详设都是为了有好的代码的，是为了在代码中规避一些风险而提前有所防范，为了代码逻辑的复杂而提前有所规划。在这个思想下，我觉得是这样的，架构是为了防范大问题和规划大结构，概要是为了防范中等问题和中等结构。详细设计是为了防范比较小的问题和小的结构。代码是要面对最细小的问题和结构。是一个对问题分层求解的过程，也就是个抽象的过程，好比把大象放在冰箱一样。

好象上面说了和没说一样，因为什么叫大，中，小，太模糊的概念了，确实是模糊，但这也正是我的想法，一个问题说它是应该架构应该解决的，还是概设或详设该解决的，这本身就是个因人而异的事情，也就是架构，概设或详设是没有严格界限，可以一刀切的。刚才说的是一个项目，不同项目更不一样，不同项目面对的问题可能会差异很大。在这个项目里不是问题的方面可能在另一个项目里是问题。第一种的论据其实是不充分的，一个项目的理解问题是大是小会因人而异，但这是个问题是共同的，一定还是要解决的。真正能支持架构和其它设计没有固定的程式，是第二种，不同项目面对的问题很有可能很不同。

所以我觉得从架构到编码的过程应该要分两个部分来学习，第一个部分是大家公认的所有项目都会遇到或者可能遇到的问题，以及大家的解决方案的经验，以及适合的表现形式，是放在架构中，还是概要设计，或者详细设计中。是适合用活动图，类图，序列图，还是用文字。另一方面，也要能够认识到不同项目会有不同的差异，要树立所有这一切都是为了解决问题，不要太拘泥于形式，什么架构一定要包含这个了之类的问题不重要。一个设计，之所以好，首先是它解决了这个项目中存在的问题而不是它的形式和格式。我说的不是不注重格式，而是说要把解决问题放在第一位，不识别问题，就抄一个设计把格式改改，弄的漂亮点，看起来好，但其实一点用也没有，如果是时间不够，还不如真正解决几个问题来的实在。

自己在这一方面也领悟不深，还是通过一个实际的示例项目来做一下，本文中只会通过项目中的一部分相关问题来写，代码在做完后会在GoogleCode开源，目的在于交流和不断进步。

注：本文持续更新中,因网页阅读太长不方便，后续文章会用不同文章来发布，以从架构到编码-需求，-架构设计，-概要及详细设计来命名。