http://xiaogui9317170.javaeye.com/blog/289822
应用架构选型讨论(PPT)
http://xiaogui9317170.javaeye.com/blog/311590
架构师书单
一、Software Architecture篇徐昊 推荐。
这个领域没有什么"畅销书"，可能读者中本来就是开发设计人员与项目经理占了多数，真正定位为架构师而且做的也是架构师工作的不多吧，你懂的尽是偏僻的人生。
《Software Architecture in Practice,2nd Edition--软件构架实践(第2版)》
第一版是第九届JOLT作品，一本被引用很多的架构书。
《Documenting Software Architectures --软件构架编档》
第13届JOLT大奖作品，捕获架构的过程，
《Applied Software Architecture --实用软件体系结构》
另一本被引用很多的架构之书。
二、UML 篇三、特定领域篇四、闲书篇 五、高效读书心得
UML、4+1视图始终是架构师界最通用的东西，寻找一种向世界妥协的方式。
1. 《UML Distilled 3rd 》
没什么特别想推荐的UML工具书，选本最薄的吧。
2.《The Elements of UML 2.0 Style 》
胜在没有同类书。
3.《UML和模式应用(第3版)--Applying UML and Patterns 3rd》
UML+RUP作的OOAD过程。
开发人员有GOF23 Pattern，架构师同样也有架构师的Pattern。不同领域的架构师需要不同的知识。
1. 公共领域
《Domain-Specific Application Frameworks --特定领域应用框架：行业的框架体验》
推荐，介绍了30个特定领域特定框架的设计。
《Head First Design Patterns》
最好的GOF23经典设计模式阐释，适合被[GAMMA95]折磨的架构师拿来复习，中文版即将发行。
2. Java EE领域
《Patterns of Enterprise Application Architecture --企业应用架构模式》
Martin Fowler老书，企业应用各层上的模式。
《Effective Enterprise Java--中文版》
Neward, Ted作品，作者学贯东西(.Net与Java)，像写Blog一样，每一页里面都有大量的信息。
可惜两本都比较旧了，没有新版。
3. EAI/SOA领域
《Enterprise Integration Patterns --企业集成模式：设计、构建及部署消息传递解决方案》
4. 网络与后台服务编程领域
《Pattern-Oriented Software Architecture, Volume 2 --面向模式的软件体系结构 卷2:用于并发和网络化对象的模式》
《Pattern-Oriented Software Architecture, Volume 3 --面向模式的软件体系结构卷3：资源管理模式》
著名的POSA2与POSA3。
《Code Complete 2 --代码大全2》
一本你教育小弟时的代言人。
《The Pragmatic Programmer --程序员修炼之道：从小工到专家》
一本你启发小弟的代言人。
《The Art of Unix Programming --UNIX编程艺术》 
刚好Head First系列开头都有一段教人如何读书的话，再加工整理如下：
1.尽量阅读中文版
虽然有人英文很强，有的翻译很差，但AnyWay 中文阅读与理解的时间，略读与快速定位的速度还是要快一些。
2.即时批注、总结笔记与交流
虽然爱书，但发现最有效的读书方式还是不断的制造脂批本，读书时在重要的文字下划线，把自己的心得写在页旁。
在明天复习一次批注，最好可以有空重新整理笔记，或者拿来与人讨论。
3.大量思考或重复记忆
看书最郁闷的事情就是看完之后脑袋空空了。技术书还好点，虽然看的时候可能很辛苦，但就像学会了骑单车，之后再骑的时候总是会的；而偏设计与管理的书，最容易的事情就是看的时候很快，看完没什么留下到实践中。
所以，我们不能以看小说的速度来看设计书，要寻找思考的机会，思考是最好的记忆。
又或者，大量的重复记忆，重复多遍直到无意识的记忆。
4.人体工学
那些见缝插针的时间与地点不是看这个书单的好地方。
环境不要有电视，音乐等强输入源，而微风阳光鸟语等弱输入源则有助活跃大脑。
看书时大量的喝水。
如果发现自己的大脑已经疲累，已经在浮光掠影的翻看，就要休息。
留给大脑消化的时间，看完书不要接着看其他有难度的书或事情。
http://xiaogui9317170.javaeye.com/blog/311588
架构师之路
什么是软件架构师?
架构师(Architecture)是目前很多软件企业最急需的人才，也是一个软件企业中薪水最高的技术人才。换句话说，架构师是企业的人力资本，与人力资源相比其能够通过架构、创新使企业获得新的产品、新的市场和新的技术体系。那么什么是架构师、架构师的作用、如何定位一个架构师和如何成为一个架构师呢?这是许多企业、许多程序员朋友希望知道的或希望参与讨论的话题内容。
所谓架构师通俗的说就是设计师、画图员、结构设计者，这些定义范畴主要用在建筑学上很容易理解。小时候到河中玩耍，经常干的事就是造桥，步骤如下：1、在沙滩上画图;2、选择形状好看、大小适合的石头;3、搭建拱桥。其中我们挑出来画图的那位光PP小孩就是传说中的“架构师”了。
在软件工程中，架构师的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局;2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等;3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。
与建筑学类似，如果软件系统没有一个好的架构是不可能成为成功的软件系统的。没有图纸的建筑工地、没有设计的造桥工程都是不可以想象的混乱世界。建筑工程如是，软件工程中亦然!
由于国内合格、胜任的软件架构师极为少见，直接导致了我国民族软件产业水平的落后。在未来以信息产业为主导的社会，信息产业水平的低下将直接影响国家核心竞争力。究其原因，无企业非急功近利、个人缺乏引导。
企业的急功近利是有无法克服的原因的，那就是社会发展总体水平。“生存是第一位的，赚钱是第一位的”，多年来许多客户抱怨国内的软件公司无法信任、系统项目累做累败、公司越换越差，但因国外不可能给中国做应用系统项目还不得不找国内软件公司做。由于人月费用低、公司开发成本高，软件企业对于应用只能草草了事，拿钱走人(很多公司拿不到后期尾款)。这样的环境下，企业几乎无法投入更多资源培养自己的架构师，加上眼花缭乱的跳槽风气企业更是不愿投入……
如何成为软件架构师?
那么要成为架构师的途径似乎只有现在较为流行的软件学院和个人自我培养了。关于软件学院我接触过不少，其宗旨绝大部分都是造就(or打造)企业需要的软件架构师(or程序员or人才)。教师来源与企业、学员来源与企业、人才输送到企业是他们办学的手段。尽管各个如雨后春笋般出现的软件学院口号差不多，但恐怕大多只是为了圈钱卖学位了事...
架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。参考软件企业架构师需求、结合目前架构师所需知识，总结架构师自我培养过程大致如下仅供参考：
1、架构师胚胎(程序员)学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c++、uml、RUP、XML、socket通信(通信协议)——学习搭建应用系统所必须的原材料。
2、架构师萌芽(高级程序员)学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice(研究生可以研究网络计算机、高性能并发处理等内容)
3、架构师幼苗(设计师)应该在掌握上述基础之上，结合实际项目经验，透彻领会应用设计模式，内容包括设计模式 (c++版本、java版本)、ejb设计模式、J2EE架构、UDDI、软件设计模式等。在此期间，最好能够了解软件工程在实际项目中的应用以及小组开发、团队管理。
4、软件架构师的正式成型在于机遇、个人努力和天赋，软件架构师其实是一种职位，但一个程序员在充分掌握软架构师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理架构、如何不断的抽象和归纳自己的架构模式、如何深入行业成为能够胜任分析、架构为一体的精英人才这可不是每个人都能够遇上的馅饼……
然而学海无涯，精力有限，个人如何能够很快将这些所谓的架构师知识掌握?这是秘密，每个人都有自己的独门家传秘笈就不敢一一暴露了。不过有一点就是广泛学习的基础之上一定要根据个人兴趣、从事领域确定一条自己的主线来努力。
如果说架构师是在模型图纸上工作的，那么模型元素必须是实实在在的，正如我们不可能期望抽象派画家来设计高楼大厦，没有实际意义的模型元素，是不可能构筑出软件系统的。迄今为止，绝大部分软件架构师是依赖软件程序员来实现他们的架构意图的，这二者直接的鸿沟是显而易见的。设计模式的出现是为缩短二者之间的鸿沟所做的努力，目的是让架构师和程序员之间有更多的共同语言和规范。尽管设计模式让软件开发效率和质量有一定程度的提升，但是它始终面临一个很明显的局限，那就是人的因素。人虽然在创造性方面有绝对优势，但是在精确性、持久性、效率、质量上是无法比拟机器的。