陈金洲 @mechiland 很早写的一篇文章，参加过 RubyConf2012 可能都看过，地址在 http://www.infoq.com/cn/articles/cjz-architecture-corruption
我觉得这是关于系统架构演化的很深刻的一篇总结分析文章，在经验上很足，对 Java 和 Ruby 社区很有启发意义。
最初提到的 AOP 的概念让我重新去维基百科 http://zh.wikipedia.org/wiki/面向侧面的程序设计 仔细看了一下，AOP 作用的范围其实是可以远超过"日志和权限"的，说白了就是业务之外的依赖技术（或者说实现业务的 DSL）才是难点，也是很多项目最终失败的原因。
发现我之前写的《人类思维和软件工程学》 http://mvj3.github.io/2013/12/15/human-mind-and-software-engineering/ 里的提到的三间段已经被 这篇两年前的文章在形式上做了类似的说明了，看来后来者走的坑都是一样的。
我把他对应的最终解决方案重新理解一下，"采用新技术"理解为"针对业务来说更精简的新技术", "重构到物理隔离的组件，将独立的模块放入独立的进程"理解为"开源和 Unix 管道工具化", "形成高度松散耦合的平台 + 应用"理解为"资源调用管理的操作系统式开发"。
和"关于文档"提到的"想象一下现在的 Rails3/Spring 框架，他们往往有超过 20 个第三方依赖，我们却没有觉得理解困难，最重要的原因是依赖隔离之后，这些模块有了独立的文档可以学习。"一样，开源是把系统架构解耦和模块化的最好手段。
这个文章很不错，适合大的长期项目的技术主管来学习一下；另外，看到这个文章让我想起来马云曾经说过的一句话，大意就是：现在的阿里集团没法管理，因为他的管理能力可以管理的团队大小是有限的，那怎么办？拆！搞成一个个小公司或者小事业部。
人脑的能力其实还是挺可悲的，"the number of chunks of information you can remember accurately with no memory degradation is only one"，所以学习新动，分解问题就很重要，如果都连在一起。。。就很困难。
有一种处理 legacy code 的方法，是一边写 character test，一边重构。代码乱了，感觉除了功力深的，没发写，所以要重构。然后写完了，可以把测试当文档用。 当然写测试，也需要很好的能力。。。
不要提架构，千万不要提架构
trivial programming 需要屁个架构啊。
能定义清楚 schema 和 protocol 就不错了
人月神话都说了，理解了数据之后，代码通常是可以丢掉的 ...
哈哈，“架构”这个词确实和“大数据”一样是忽悠人的：）
我也和你理解的一样，真正的架构都蕴含在 HTTP，数据库，编程范式里了，而另外一端就是在一个项目里做细节性的编程。不过有些项目真的比较大和难，比如 12306.cn，两端得很深地结合在一起思考。
人月神话说的”理解了数据之后，代码通常是可以丢掉的“确实没错，因为这里的代码指的就是业务代码，公司上下都理解业务，当然这代码就微不足道了。”数据“就是一种设计啊，它是我们好用的"家电"。
#10 楼 @bhuztez 因为垄断了所以会难搞，因为供远远小于需求，所以会难搞，可以看看这个 http://coolshell.cn/articles/6470.html 搞好一个最大的卖票网站远比你想象的复杂，高并发会让所有简单的东西变得超级复杂