同求。

推荐《Beautiful Architecture》

#2 楼 @KgTong Google 了下，竟然只有一颗星

#3 楼 @iBachue 这本是上软件工程课时老师推荐的，我看了几章，感觉挺好的呀

#4 楼 @KgTong 那就不知道为什么这么低了

#5 楼 @iBachue 其实说来说去就是架构那四招不停地结合、不停地优化

《Enterprise Integration Patterns》

Bug??

.replay{ min-height: 65px; }

把代码写得更好。

#8 楼 @shatle 我去……

感觉这不是书上容易教的，只能自己从一个坑一个坑慢慢爬...

#12 楼 @fleuria 如果是的话，那么应该有一个“坑列表”的文档，然后过一遍就可以学到相当多的东西，而不是实战去硬拼。

#6 楼 @KgTong 请问哪四招？

#10 楼 @emanon 这个还是代码层面，而不是架构层面。

#6 楼 @KgTong 是这几个吗？ http://msdn.microsoft.com/en-us/library/ee658124.aspx

• Separation of concerns
• Single Responsibility principle
• Principle of Least Knowledge
• Don’t repeat yourself (DRY).
• Minimize upfront design.

微软有很多资料啊： http://msdn.microsoft.com/en-us/architecture/cc511514.aspx

#8 楼 @shatle 已修好

#14 楼 @linjunhalida

1.分层:C/S、B/S、多层,数据、计算与显示的分离(MVC) 
  一个模块做很多事情，各负其责,分工明确
2.异步:事件、消息
  请求之后等待结果(同步)请求之后继续执行,后续等待结果(异步) – 性能(吞吐量)提高,但实时性变差
3.缓存:页面缓存、数据缓存、消息缓存
4.并发(分布式):集群、负载均衡、分布式数据库
  原本一个模块处理很多请求、多个模块共同处理这些请求
  提高了吞吐量、响应时间、可靠性,但需要考虑同步等复杂问题

#15 楼 @linjunhalida 写代码就是架构。你也说了，层面不一样罢了。如果一个程序员两句代码都组织不清楚，如何放心让他去组织更高层面的东西？不过似乎这样的“架构师”蛮多。

我觉得程序员中代码写得好的继续当程序员，代码写得很烂的可以安排他去当架构师

同意 #20 楼 这儿就有个，一个函数 10 多个 if，嵌套层次很深，也是架构师，难以理解。架构应该是慢慢积累的，还要在项目中取检验，不同的项目因环境和数据量、业务场景不同而无法 copy 架构，但是别人的架构是可以欣赏的、可以借鉴和学习的。#21 楼说的很对哈。

#20 楼 @emanon 代码的概念比架构宽泛的多，写代码未必和架构有关

如果说架构方面的知识学习，我没见过比 REST 论文更合适的了，我在这之前看的书都没能让我理解什么是架构，而这篇论文水平低和水平高的人都能看。

参考： http://www.infoq.com/cn/articles/doctor-fielding-article-review

#22 楼 @debugger 嗯，我也蛮不理解那些把别人分享出来的“架构”经验直接搬回来用的。这些人一般也都比较喜欢玩“大设计”、套用模式、预先设计、当预言家。