如果把数据看成是厨师要加工的原料的话，那么厨师如何加工的厨艺是架构的核心，如何处理数据等同于如何加工原料，其中实际就是方法论问题。

我在蒯因与引用透明也提到，当你掌握形式逻辑方法论以后，无论在数学这个形式语言还是在软件编程架构这个形式语言中，都有处理数据的依据和核心。

我们也不能提到数据或数据结构，就联想到数学算术(数据运算)；面向对象也是处理数据结构方式，也是一种数据的边界封装；技术架构中提倡数据和程序分离，存储和计算分离，数据的不变性；计算的引用透明性。统统这些都是数据的加工方法。

再回到厨师这个案例，如果说数据就如同切菜板上待加工的静止的一块肉，是一个被动物体，那么我们如何去切这块肉的方法则非常重要。

什么时候程序员意识到“Hold住事件”比“Hold住数据”更重要，就意味他摆脱了数据库阴影，走上了架构之路：NOSQL基于事件的事务实现

数据管理的未来: “Disk-less” 风格数据库?
[该贴被banq于2011-08-31 13:15修改过]

楼主显然没搞明白一个问题： 服务谁？

楼主所说的架构师服务对象是服务程序的程序员。

我觉得这可以和砌房子类比下：

我觉得数据结构和算法是基础，这个是砖头，如果是砌小房子，比如嵌入式开发这种，我觉得还是需要考虑砖头怎么造的，怎么样效率，稳定，省料。

架构这个东西我觉得是一个建筑风格和艺术，是一个比较高的层面，根据客户要求来设计不同风格，外形，功能的房子。 比如球形，方形，太阳能。 在这个层面我觉得去研究砖头没什么意义了。 你要考虑的是怎么利用现有的，一些经过验证的真正好用的技术（nosql。。。），来搭建一个健壮的房子。 砖头的选料我觉得那是一个调优手段，但不是重点

我不知道他的具体意思是什么，我读了文章如何打败CAP定理？突然明白：能够打败CAP定理是因为我们对业务数据有了深刻的认识，这篇文章虽然没有谈OO，但是他的对数据两个重要性质的概念其实是两个OO概念；状态和值对象。

所以，与其说架构离不开数据结构，不如说架构离不开业务分析，这两者等同的。海量数据抛弃OO说法是片面的，也符合Disruptor并发框架的LMAX团队认为的：Modelling Is Everything，高性能高可扩展性的架构方案只有对业务数据充分理解以后才会形成。

我这个观点不是否定基础，而是强调根据方向选择基础，打个比喻：比如你的方向是修桌子，那么基础是你会使用锯子就可以，会用锯子是基础，但是如果你是专业想鲁班那样的木工，那么自己造锯子就可能是基础，但大部分普通木工的基础都是用锯子，而不是为了修桌子或做个普通木工而去专门学习造锯子，造锯子还有基础呢，打铁啊，你学得完吗？最后你沉浸在基础学习中忘记你为什么而学，何以学以致用呢？

另外一个问题还要注意：防止无穷的基础知识会掩盖你天然无穷的创造力，你成天都在学习那些间接知识，何以有时间在前人基础上创新应用呢？

搞技术应用的人和搞科学研究的人应该有两种不同思路，后者是根据基础决定方向，比如你的数学基础好，你将来可能从事数理研究，做数理方面的博士，你可以花10年不断地在原来基础上再加基础，可是搞应用不同，没有那么多时间。

我通过这篇文章：不变性设计，希望起到对当前软件开发和架构设计主要方向重视起到提醒作用，

我经常在国内各种知名媒体和交流活动或微博等等场所看到的都是基于数据库的编程研究，和大捧JVM底层机制或Tomcat底层等实现原理的思想，我不反对你有精力可以研究学习这些更好，但是要知道应用编程主要的方向在哪里？走错了方向浪费自己的青春年华无疑于慢性自杀，与其那么多年走一条可能错误的不归路，不如不要做这个行业，无为，对自己对年轻人都是一种促进和帮助。

[该贴被banq于2011-10-21 10:16修改过]

云： 这个技术是一个概念，其本质就是分布式计算，分布式计算的基础是图论和并行算法。图论和并行算法的基础是什么？
集群： 这个是一种多虚一的特例，依然离不开图论与并行算法。图论和并行算法的基础依然是什么？
单点风险：主要依靠无状态和负载均衡，如何实现负责均衡呢？你自己去想，不用我说你自己就想数据。负载均衡是不是也是图论和并行算法？

我想说的是，难道汽车设计师也需要知道汽油是怎么炼出来的？钢铁是怎么练出来？
软件工程是讲究层次的，每个层次的人关注的点不一样，软件架构师关注的更多的是软件的主体结构和领域模型的抽象。而软件架构师因为在某个领域经验丰富因此可以提炼出更可靠的模型。