架构之谈

[babituo]

前些日子庆哥盛情邀请我谈谈一般性的软件架构问题。
我的第一感觉告诉自己,这是个不好谈的话题，
谈雅的，东抄西抄IEEE标准定义和教科书内容的,已经有不少了,
谈俗的，则容易被雅士们扁。
难啊，我萌生了推辞之意。
可转念一想，
觉得这正是一个具有挑战性的话题，要谈的话，也许能谈出一点新鲜玩意来。
苦思良久，今日竟然顿悟：

“架构=整体-部份之和”

一直以来，我们对两个问题的答案总是处于混沌的状态。

1.整体大于部分之和的是什么？

我们说，系统科学研究的是“整体为什么会大于局部之和”的问题，

“1+1>2”
“团队精神，团结就是力量”
“一根筷子容易折，一把筷子折不断”
“项目经理的任务就是带领一群绵羊去战胜一头狮子”
...

以上这些是我们经常用来解释整体大于部分之和的话语。

那么，整体为什么会大于部分之和呢？整体大于部分之和的又是什么呢？
似乎，我们一直没有找到一个简单明确的词语来表达这个“什么”。

2.架构到底是什么？

说到“架构”，一般人总是会油然而生一种敬畏，似乎这应该只是大师们的语料。
大师们的话总是那么深睿，那么神秘，让我们这些普通人琢磨不透。
想体会这种神秘感的话，只需要用“架构的定义”为关键字去网络上搜索一下，
在这里，对此我就不多说了，总的说来，就是对架构的定义，我们目前表达的还不够浅显易懂。

我曾经试着给架构下一个简单的定义是：“架构是资源的整合者”
其基本含义的出发点是：
架构作为动词，是一种对构建性行为的表达，构建性的行为就是使用资源来构筑目标实体的行为。
那么架构作为名词，就应该是将资源整合为目标实体所用的机制和结构。
当然，这个定义并没有被流传开，我也不知道它比大师们的定义有什么差距。
自己感觉，我自己的这个定义还是不够浅显易懂。

庆哥的邀请，让我不得不进行良久的思索；
于是，这两个问题，今日在我头脑中相撞，让我得到了一个至少让自己震惊的结论：

“架构 = 整体 - 部份之和”

也就是说：

“整体 = 架构 + 部分之和”

原来，
一直让我们琢磨不透的那个“整体大于部分的和”的东西，
一直以来我们在用另一个让我们琢磨不透的词语“架构”在指称，
而我们一直都没有坚定地、明确地、理直气壮地这么宣布。

[刘庆]

多谢邱兄的畅谈，对文中观点，感觉有点玄，有些深奥，不大懂。

 

架构这个词也是流行起来的吧，以前是不是叫总体设计的那个？邱兄显然已经抛开其字面的定义，而转去寻求它的本质，得出"整体＝架构＋部分之和"的结论。

 

可整体是什么？部分又是什么？这个问题岂不是又会陷入循环当中吗？譬如说一栋房子，是一个整体，有房梁，有砖瓦，有门窗，这些可以算是房子的"部分"了吧。而架构存在何处？可以理解为是布局或是结构吗？将建筑和软件进行类比是软件行业的一个传统，连架构（archtecture）本身这个词的含义都跟建筑有关。可以那一个例子，桌子上面摆着一部手机（当然我们可以想象这是一个刚设计出来的型号）。可以将它看作是一个整体，显示屏、按键，还有盒子里面看不见的电路芯片，应该都算是这部手机的部分。而抛开这些部分之后剩下的还有什么呢？

 

显然，这些剩下的东西是无形的，例如为什么按键设计成圆形的，显示屏如何在盒子里面跟电路版接上。例如这个接头，是连接显示屏和电路版的，如果在软件里面，我们可以称之为"接口"吧，它连接了两个模块。但如果是指物理的接线盒，那还是手机的一部分。因此，就像我们通常说得无形资产一样，将品牌、技术、知识、专利等无法估价的东西叫做无形。

 

因此，邱兄的表达式倒不如表达成为：整体＝无形的东西＋有形的部分。

 

暂时不知道无形的东西是什么，所以只好称之为"东西"，而认为这"东西"就叫做"架构"，我认为还是有些不对劲啊。那其实是将架构泛化了，但它其实没有那样多的含义。说"架构是个无形的东西"，我还可以接受（但不敢确定）。因为如果架构作为动词表示一个过程，对于最后的整体来说，肯定是无形的，而如果是名词，作为一种结构，也是体现在最后的布局方面，也是无形的。但如果说"这无形的东西就是架构"，下意识是深表怀疑的。如果举个例子反驳，来试一下。还是用这个手机来举例子，这是个诺基亚手机，我认为这种设计比旁边这部康佳手机的要简洁。得出这结论，一方面可能是因为确实简洁，一方面可能就是品牌这个无形的东西在起作用了。

 

将架构定义成"架构是资源的整合者"，这当然是非常简单的定义，但恐怕缺乏限定词，这样说太笼统了。因为我也可以说，"企业管理者是资源的整合者"，但显然架构和企业管理者是不同的玩意儿。

 

发现自己觉得例子都不是软件本身的，这是不对的。因为这里谈"架构"一词，实际上是在软件这个领域里面谈。那么试着来举个软件的例子看看，研发一个客户管理系统，要架构，也要项目管理，这些难道不都对最后的系统（整体）产生影响吗？如此，将项目管理就明显区别于架构的。

 

总体来说，对于邱兄的观点我不能完全赞同或是否定，只能提出反驳依据，重在探讨。

 

 

 

[goldenfish3]

架构应该等同于总体设计吧。总体设计是什么，应该比架构更容易理解。架构这个词搞出来后，什么东西都能安上“架构”之名，不只是在软件范围内讨论，而是在软硬件集成的范围内讨论了。一个系统，有目标架构，有逻辑架构，有物理架构，有安全架构，有元数据架构，有接口架构，有应用架构，有分发架构，有无穷多的架构，能听得人吐血。甚至超出系统集成的范畴，还能有业务架构，流程架构，组织架构（这个东西倒是随处可见）等等。或者架构本来就是从其他领域来，到了IT圈里被四处滥用。不过换汤不换药，东西还是那东西，不就是总体设计嘛。

 

[babituo]

呵呵,有庆哥这样的谈友真是幸运.
我显然是先从架构的本质效能的角度切入来谈的,庆哥已经看出来了.
为什么会有架构这种东西存在?它真的是无形的吗?还是我们没有把它的本质定位搞准确?
一旦你抓住这个本质的定位,其他任何的理解都可以从此衍生,不信,我们可以进行推衍.相反,不抓本质,

泛泛而谈的话,正好可以得到目前架构运用的结果:架构混乱,滥用,1+1<2,等等等等.

庆哥也知道,凡是都要问个为什么?追问下去,就会找到本质,找到本质就能顺利地回溯,指导我们设计.
我喜欢从本质回溯地往外谈事,但这并不表示我不关注具体的应用层面.
我理想中的探讨方式是:探讨的各方能够迅速地站到相同的领域,相同的层次,相同的视角和相同的视域内

,交换各自看到的图景,随着探讨的深入,我们会逐渐变换到相同领域的每个层次,每个视角和每个视域,交

换我们各自心中所有的视图.
不理想的探讨会比较浮躁地用不同视域的图景来相互辩论,这样的辩论本来可以用共同转移视域来避免的

.

也许庆哥会习惯性地觉得我上面这些"条条框框"比较难懂,即使懂了,也难以照办,即使照办,也会压抑思

路.其实,这正是彼得.圣吉所倡导的"深度汇谈"的方式,而且,我上面对这种汇谈方式的表达已经相当具有

BI风格了,可惜,我们中大多数人是不知道的,这正是进行科学管理,培养学习型文化所面临的挑战.

这是我预料到的结果,所以,在遇到我明知是不理想的探讨方式的时候,我不会付出太多的耐心,毕竟,我的

职业不是讲师.

谈回架构问题,
我们可以顺着"架构是用来整合资源的机制和结构"的这个本质效能表达的思路去推衍所有架构存在的理

由,并验证所有对架构理解的真伪.
我们就仍然暂时先不去谈"软件架构",模仿大师们的足迹,我们也先谈"建筑的架构",不过,谈法稍有不同,

是从我的本质效能的表达出发来谈的.

建筑是什么?从表面看,一次建筑活动的整体目标是建设一座事先设计好的建筑物,从本质看,一次建筑是

满足一个社会群体的某方面的社会活动的需求.是通过将自然资源----水,泥沙,石头等等,整合为满足目

标社群某类需求的实物.水,泥沙,石头等不能直接满足,只有将它们整合起来,才能满足,这就是本质.
建筑满足的需求是什么呢?居住,从能挡风遮雨到舒适惬意;通行,从能坚固耐用到能安全顺畅;观赏,从能

独具风格到能体现文化魅力;纪念,从能寄托情感到能永垂千古;建筑,首先要整合的,是这些需求资源,其

次,才是水,泥沙,石头等工具性资源.
于是,我们会透过"建筑布局","建筑结构","建筑装潢"看到所谓的"建筑风水","建筑风格","建筑空间","

建筑效能"等等.无非就是整合建筑资源满足建筑的需求.

建筑是如何来整合建筑资源来满足建筑需求的呢?其机理和结构是什么呢?这才是建筑架构的内容.
我猜想，建筑师要涉及一座建筑的架构，他首先要做一件事：
确定业主和业主的需求，主要是得到业主对建筑规模的预计。
如果是小规模的建筑，只有功效的需求，架构起来比较简单，也许根本不需要建筑师出马，找个工头就

搞殿了。
对于大规模的建筑，才会有风水的需求，风格的需求，空间的需求和功能性能效应的需求。
对于风水和风格的需求，建筑师要考察当地的地质水文，风土人情，文化习俗，建筑风格，业主心理，

业主习惯等等，建筑师需要设计适当的地址，朝向，基础结构模式，空间布局，建筑外形，装修风格等

等来满足。
对于空间需求和功效的需求，建筑师和结构师会利用理论力学，材料力学的原理，来设计出适当的建筑

外形，基础结构，空间划分结构（梁柱板墙结构）来满足。

当然，建筑架构设计的内容，远远不止我这里谈到的这些内容，我这里只是站在外行的角度来理解而已

。建筑架构设计的本质，在于运用"力"。拉力，粘力，压力，撑力，扭力，张力，摩察力，冲击力等

等，运用各种力的效应，化解各种结构的问题。有意思的是，我发现，对于抽象的精神需求结构，也可

用同样抽象的信息力的原理来化解，我认为，这正是建筑架构和软件架构相通的本质所在。

象我这样的建筑外行也可以斗胆猜测一二，得益于我对架构本质的"瞎"捉摸，希望得到真正的建筑专

家的指正，毕竟，我不是职业的建筑师，我只是一个普通的软件架构设计人而已.

另外，关于整体和局部的关系问题,正好前段整理了一篇帖子,在我的坛子上,给庆哥参考.
http://www.smarthings.net/bbs/viewtopic.php?t=37
帖子的名字叫"面向对象的'套箱结构'"

[刘庆]

非常赞同邱兄关于讨论问题的方法，抛出观点，围绕观点进行探讨，甚至争论，一直也是我期望能够在ttnn达到的效果。

 

这篇文章中，我的理解是将"架构"引到如何运用"力"上来了，从建筑领域中建筑师运用物理的力，到软件领域中架构师运用抽象的信息力。邱兄对于建筑的事情还是蛮在行的哦，我上篇文章中也是想引用建筑的例子来着，可惜，想来想去，确实对那个行当没有好的理解，只好作罢。还是说说软件行当里面的例子吧。

 

从"架构是用来整合资源的机制和结构"，到"架构的本质是运用抽象的信息力"，这两句话的意思应该是指同一个东西的，前者是谈作用，后者在方法。不知这样说对不对呢？在理解这两句话的时候，我也有所感觉。原来所提到的整体、部分，提到整体去掉物理的部分，其实还有后面"无形的东西"支撑着。如此看来，这无形的东西甚至就包含了"抽象的信息力"，但这样说就太过于泛化。

 

而再想想，架构有一个特点，不论是动词或是名词，他都没有直接体现在最终的交付物上面。最后的交付物也就是"整体"。当架构是动词的时候，是指在构建这个整体的过程，当名词的时候，是一种机制和结构，也是用来支持这个"整体"的设计过程。即，架构是交付"整体"之前的活动（动词）或支撑（名词）。

 

在建筑领域的例子中，如何运用物理的力，这里的力是一种自然存在的，显然建筑的架构是运用这种自然，是人力的。而我又在想，如果同样想象软件领域中那个信息力，这个"信息力"也是自然存在的？而架构也是人力的吧？

 

不好意思，思维已经乱七八糟了。今天是端午节，到佛山，快下午六点，在移动大厅里面等着回去的车，外面正下着大雨。这里有个好处，在于可以无线上网，而且没有什么限制，好极了。我已经很久没有不受限制地上网了，便打开电脑，顺着邱兄的思路，也想想架构的事情。可写到此处，自己也不知道要表达什么东西。

[babituo]

我推出架构的本质功效的定义,如果不引起争论,是我不期望的.
我期望争论的反面观点是:
架构的本质功效,不是整合资源,而是做别的什么用?
或者,
主要起整合资源作用的,不是架构,而是别的什么东西?
架构的有形无形我暂时还没有谈到,
我的观点是:架构既有无形的部分(机制)又有有形的部分(结构和风格).

为了讨论方便起见,约定后面谈到"架构"一词,专指其名词含义.
"架构是用来整合资源的机制和结构",这句话既表达了架构的本质作用:整合资源.也表达了架构最主要的名词性解释:机制和结构.
"架构的本质是运用抽象的信息力",这句话表达了软件架构机制的本质:软件架构为了整合信息资源必须遵循的信息作用关系的一般规律.尤其表达,信息作用关系是可以和物理世界的力的作用关系相类比的观点.
架构不专限于交付物交付之前的起支撑、粘接、传导、约束等作用的物体，更主要的是，交付之后，这些物体以及它们起到的作用效果仍然是构成交付物的关键要素。“整合”不仅仅是一个过程，同时，还是一种功用，例如，“柱”的整合作用是它支撑了“梁”梁的整合作用是它支撑了墙和板，而墙和板的整合作用是它区隔了空间。只有在这样的整合作用下，砖，沙，石，钢精，水泥，木板等资源，才能组合成具有一定风格和功用的建筑，才能达到最终的目的：满足用户的需求。

我之所以突出架构的功用，是认为，只有突出功用，才能联系需求，而需求，不仅仅是一个具有功能和性能的交付物这么简单，还有凝聚在交付物上的经济价值，审美，文化，品位，风格，吉凶（心理暗示）作用等诸多的元素，这些元素聚集在交付物上，应用于特定的用户环境，才构成整体，这才是比较完整的需求。只有架构，才能帮助那些零散的资源，达到这样的整体效果，当然，好的架构，会得到好的整体效果，差的架构会得到甚至相反的效果。恶劣的组织甚至差过散兵游勇，就是这个道理。

因为在公式：整体 = 架构 + 部分之和
中，架构（起到的功效）可能=0，>0或<0;

随着讨论的继续，我的话题会转向软件架构，并希望能最终谈到BI系统的架构，当然不是我一个人能做到的。但始终会贯穿一个观点：“整体
= 架构 +
部分之和”，也就是："架构是用来整合资源的机制和结构"。

[刘庆]

突出架构的功用！太好了，对此，我有话要说。

 

但不想继续谈的太虚了，因此，从追求本质中脱身而出。结合到具体的例子和环境当中，例如谈bi的架构。上个月花了很大的篇幅讨论了数据模型分层的问题，这应当是架构的一部分，其目的是为了区别对待数据，使数据处理过程清晰并使提取数据性能提高。

 

这是分成ODS、DW、Staging Area等层的目的，架构总得还有其他一些内容吧？例如数据质量如何管理？如何保证管理员能够了解数据的来龙去脉？如何让用户高性能访问数据？如何让用户作OLAP分析？如何让用户作即席查询的分析？如何提供报表？等等。这都是数据仓库架构师需要面临的问题吧。

 

因此，谈架构还得谈它所面临的需求。对于整个系统来说，它会面临最终用户的需求，架构的考虑也是满足这些需求，但又不是在具体的业务逻辑层面，而在在系统管理层面。如果将一个系统的用户分为业务角色和系统角色的话。

 

这两种角色，都会提出的功能性和非功能性需求。例如一个市场人员希望每天能够看到销售日报，并且能够钻取到每个地区或是每个产品线，这是一个功能性需求。当然还有非功能性的，例如要求在5秒之内能够看到结果。一个DBA需要能够分析用户访问日志，用来优化数据库设计，或者一个ETL管理员需要监控每日的ETL进程，一个质量管理员需要得到每日的数据质量报告。或是一些环境约束，存储只能是多少，操作系统是什么等等。

 

架构的需求就是来源于业务角色的非功能性需求，以及系统管理角色的需求。

 

因此，如果要去作一个架构，不妨去将这两类角色的需求作个列表。不同的需求当然会有不同的架构。例如在根本就没有OLAP需求的时候，何必再去考虑架构中如何实现OLAP呢？如果没有数据质量管理员的需求，恐怕也不会在架构中考虑这个问题了吧。如果还有其他的一些约束，例如存储暂时只能给出500G，一年以后才能给出3个T，那么还是先就着这一年的500G来设计数据仓库，那就得考虑，是否需要单独的ODS，DW的数据保留多久等等问题。而如果项目工期上面还有约束，例如要求在半年之内上线，那你可不就得考虑是使用EDW？还是短平快的数据集市架构？（此处我称作架构，但也有人成为方法论、方式等，看来确实是够滥用的。）

 

就算看看上面谈数据仓库架构的例子，是否符合这个"本质"定义呢？当然符合，就好像说"人是一种生物"，或者说"人是一种原子、电子组成的电路体"。这种说法没什么意义，好像是在作魔鬼字典一样。如果要说得直观明了一点，可以谈"究竟为了什么目的"。

 

哦，我现在将"目的"这个词提的数量不少，内和外的区分也是用"目的"。这个目的本身也不是一个特别明确的词。其实，这里的目的，和前面曾经出现过的词，如需求、功用都有在说着差不多的意思。

 

如果拿到老庄那里，也就是他们说的"用"。一件物体是因为有"用"，才被设计的。一种简洁的，恰到好处的满足了"用"，就是一种好的设计。例如一柄螺丝刀，分成不同尺寸、不同长度、不同花型，有不同之"用"。也有那种多功能的，可以拆卸手柄的，但有没有发现那种多功能的，大多不是专业人士的选择。一项好的设计如果出现了多余的，就该去掉。所谓多余，并非完全没有用，只是用处不大，可以将它单独考虑。还有一种"天地设计论"不是说这个世界是被设计出来的吗，以前有个信基督的朋友经常念叨这个。看，这周围的一切运转的多美美妙、和谐，怎么出来的，上帝设计出来的。原来上帝是个最牛比的设计师啊。如果再看达尔文的进化论，物竞天泽，那些没有用的东西，不能适应环境的东西就会消灭。譬如人身上的尾锥骨，譬如阑尾，没用割掉也无所谓。

 

前段时间看到inmon推出的DW2.0中，提到将数据按照不同访问频度而分类，并会放在不同的物理位置，例如有的一年也只访问一次，可以放到归档区，有的天天被访问，就放到交互区等等。我认为这是一种不错的设计，应当也是上面 "用"的一种体现吧。

 

说到此处，发现自己话语种，"架构"一次渐渐被"设计"这个词替代。嗯，其实这个词的含义比架构更加广了吧。如果说"设计＝整体－部分"，说"设计是整合资源的机制和结构"，似乎也是不错的。但设计这个词用的领域很多，广告设计、美容设计、资费设计，可那些场合，很少说架构的。如果一个美容店老板说"我给你作个美容架构"，也挺恐怖。

 

回到软件领域，传统的软件工程里面是怎么说的？需求阶段、设计阶段，需求阶段确定的是"问题域"，设计就是要给出解决问题域中问题的方法，当然也可以用机制和结构来形容。因此，当以往的讨论专注于，设计是什么的时候，也可以来关注另一方面，"如何才是好的设计"。我想不一定非得说清楚是什么的问题，才能作出好的设计。

 

在软件中的这种设计，我认为最终要的衡量标准就是是否合"用"，也就是是否不多不少地符合需求。这点和艺术上的设计似乎有些区别，至少看起来是的。艺术领域，设计强调创新。当然如果去追求本质，也是一种"用"，但这种"用"是一种快速消费的。例如设计一套时装，基本的"用"是可以蔽体，可现在这种"用"已经退化到另一种审美之"用"的后面，这衣服漂亮、酷、和别人不一样才是一种"用"。如此的"用"，用了一边，再第二边，可能就大打折扣了。不是有人说，第一个将美女比作花的是天才，第二个是庸才，第三个是蠢材吗？恐怕也就是这个道理。

 

这一套拿到软件设计里面，倒不能成为标准。软件设计提倡复用，不过分追求标新立异。当然，这种复用大多停留在代码、模块，往上层一点，可能是设计思路本身（设计模式），甚至是分析思路（分析模式）。在一项软件设计里面，如果你用到了以往的代码，会认为是聪明之举，可以节省好多测试时间。如果你用到设计模式，会认为是个设计高手；如果用到分析模式，就被认为是个大师。这些都好像在"利旧"，那里能够体现设计者的设计能力呢？也许这就是软件设计和艺术设计的不同吧。前者在从事一种工业活动，追求效率为先；后者是一种艺术活动，追究审美为先。但也不要忘了，即便在软件领域，也有人在设计那些模式哦，这样的人，比大师还要大师，算啥？就算是"老"师吧。
 

[babituo]

如果我们用来指导设计的概念都是不清晰,甚至是混乱的,那么,我们的设计的成功率,就只能靠经验和运气了.

看来,庆哥还是没有理解到架构的有形部分,以至于可以把"设计"和"架构"的概念搞混淆.
"一纸设计"和"一体架构",是不可以相互取代的。
我举这么多"柱啊,梁啊,板啊,墙啊"什么的例子,不要让我白费心思啊.

"架构的需求就是来源于业务角色的非功能性需求"这是官话,是没有错的,但我要问:
为什么呢?
对"非功能性需求"和"功能性需求"你又是如何界定的呢?
有没有什么功能性的需求,就是对架构提出的,必须用架构来满足的呢?
比如,我要一间30平方米的办公室的空间,公司需要一个200平方米的会议室的空间,
这是功能性需求,还是非功能性需求呢?.这明显是要用架构设计来满足的.

架构和需求到底是什么关系呢?
当然是解和问题的关系,笼统的一句"架构为满足非功能性需求而设计"显得非常含混,很虚.
但如果说,"架构是为将零散的资源整合成为一个有用的整体而设计的",就显得明确了很多,实在了很多.
庆哥为什么不对比这两个描述,回头再看看自己所谈的"实内容"呢?

需求是问题和机会,需求是目标,是想知道什么,想改变什么,想得到什么的渴望,但每个需求都不会自动满足,也不会唯一而纯正地得到,需求和不需求会同时到达,这种需求和那种需求会有关联和约束,这种需求满足多了,那种需求就可能满足得较少，甚至还会另外得到一些想“不得到”的结果（反需求）.
所以,需求之间,需求和反需求之间具有结构关系.

满足某个功能性的需求的,可以是一个经过小规模整合的实体,但满足一系列相互关联的功能性需求的时候,就要将哪些小实体当作资源,进行更大规模整合。再次提醒庆哥,"整合"不仅仅可以表达一种行为,一种设计概念,还有实施整合时所需要的实物,这些实物及其配置关系、与其他资源的配置关系,就是架构的有形部分.
所以,需求是综合性的,是有结构的,这种结构,不仅仅牵涉目标需求内部的权衡,还且还牵涉和影响到与目标反需求和目标外的需求和反需求的权衡.

需求靠整合资源来满足,我们在就要在设计和制造目标实体的时候,在真正进行资源整合的时候,充分的考虑对资源的合理使用,合理配置的问题,比如,设计三峡大坝的时候,就要考虑如何解决对生态平衡的破坏问题等,这些,就是架构设计和架构实施的内容.

因为需求有结构,所以满足需求的资源配置也必须有结构,而且二者必须匹配，这才是架构设计之所以存在的真实原因.

谈到架构师,实际上我们中大部分的架构师只是架构使用师(工程师),而非架构设计师.真正的架够设计师,就是那些设计广为流传的设计模式的大师们,由于我们中大多数人都还只是"架构使用人",偶尔出现一两个"架构设计人",大家都会不认识的.这很正常.

本来这次是可以谈点"实"的东西的,
但我总是发现我们有太多的"虚失误",不解决"虚失误",难道可以根本解决"实错误"吗?这是个相当让我们困惑的问题.

[刘庆]

讨论越来越长，理解起来已经成为力气活了。为了便于讨论，我将上文邱兄的观点抽象一下，请看是不是对啊。

 

1、架构也包括有形的部分；

2、架构和需求的关系；

  2.1 需求之间是有结构关系的；

  2.2 需求的结构和资源的结构必须匹配，这才是架构的作用；

 

下面就上面几点谈谈自己的想法。

 

首先是架构也包括有形的部分，邱兄前天举出柱、墙等例子，我并没有将它们理解成是就是架构，以为说得是架构的功用。而对于架构，通过这次讨论，我越来越相信它是一种无形的，作为过程时，大部分是一种脑力劳动的。如果将"柱、墙"也当作是建筑架构的一部分，那么岂不是也和邱兄之前所言的，和"架构＝整体－部分"之论断冲突吗？柱、墙如果属于架构的有形部分，那么它是否还属于整体的一部分呢？

 

当然，这种讨论有些流于扣字眼。因为文字的表达力是在有限，人的表达又更逊一筹。譬如说此处的柱子、墙，既可以理解成为是实际看得见摸的着的物体，也可以理解成为是建筑师脑海中可以承重的概念。我认为这种术语架构范畴的应当是后者，脑海中的概念，也就是无形的东西。

 

好了，第一个问题讲完。

 

第二个问题，之前我所说什么功能性需求之类，并非对架构作定义。原话是"架构的需求就是来源于业务角色的非功能性需求，以及系统管理角色的需求。"，这是在说架构的目的从何而来，当然，所谓功能性和非功能性需求这两个概念本身是没有明确被定义的，因此，这句话就是模糊的。这句话只是加了两个限定词，一个是角色的分类，一个是需求的分类。

 

对于2.1这个说法，其实我不太理解所谓"结构"是什么，但我相信某个需求和另一个需求之间肯定存在某种关联和约束的。例如一个分析师需要查看一个多维cube，系统管理员需要监控系统使用状况，这两个需求之间当然有关联，分析师的行为要体现在管理员的监控界面上。约束也会有，这是一种更强的关联。譬如一位领导要在每天上班9：30之前看到昨天的销售报表，一位质量管理员需要在每天9：15确定数据质量是无误的，当出现质量问题，要考虑是否在9：30展示那些数据。这应该算是一种约束吧，但不知道是不是邱兄所说的。

 

如果这样理解，需求的结构，就可以认为是由若干不同的角色的子需求的汇总，这些需求之间存在关联、约束、包含，以及其他我暂时想不起来的关系，重要的是每个需求不是孤立的点，浮在半空。这样的理解对不对？如果是这样理解，我认同。

 

至于2.2点，既然需求有结构，资源也是有结构的。资源这个词是在太泛泛，要知道人是资源、时间是、金钱也是、原材料也是。因此我都不知道该说什么好。但如果放在软件领域，当架构一个系统时，这些资源应该是包括人、时间、代码、库、机器设备等等了。架构是为了让这些有结构的资源和有结构的需求合在一起，而且是那种像齿轮一样的紧密匹配。是这样理解的吗？如果是这样理解的，我也认同。

 

对于架构的功用，重在整合，我认为这种抽象的说法没法去争论，要不扣字面意思，要不就谈具体的例子。既然邱兄本来是要谈"实"的东西了，可对我的一番说辞又产生疑惑，认为要澄清这种"虚失误"。这点也是我和邱兄观点不大一样的地方，我认为这种"虚失误"总是存在的，能够有个基本的一致，就可以继续谈实的东西。从这段讨论来看，咱们应该没有本质的理解差异。

[babituo]

本来我的公式是这样写的:整体=架构部分+其他部分之和,嫌罗索,结果引起理解偏差.后面怎么解释也扭不转了.先回这些,我们的理解还是存在关键性差异.