架构设计的高级问题 ！！！有请孟子，大灰狼，SP123等等牛人。
我的问题是这样的：在架构设计完成后，如何通过良好的检测手段来验证自己设计的架构是否合理。传统的手段是在编码阶段，或者等项目完成了通过实践来验证架构的合理性。但是这样如果架构被验证为失败，那么整个项目也就失败了。
需求的验证可以通过通过与客户的沟通来确认，
编码的验证可以通过测试工具来验证（unit），
那么架构的验证如果来实现呢？？？？
如果您知道请说下，希望通过理论和具体步骤的方式来说，光说理论也没意思！！！ --------------------编程问答-------------------- 架构要登若干年吧 --------------------编程问答-------------------- 架构无须验证，也没有办法直接验证。不管什么架构，如果在给定的时间和给定的费用内，完成了客户需求验证(业务功能实现、用户体验、性能和Availability)，那么就可以说这个架构是合理的。
架构的验证是通过客户需求的验证来间接验证的。
自己也觉得上面的话有失欲偏颇:) 大家批评指正！
--------------------编程问答-------------------- 架构的验证是有理论基础的。。。可以验证，只是我自己不会。。。也不知道。 --------------------编程问答--------------------
好像隨著自己的不斷成熟，每個階段的架構都不太一樣的。
其實一個大項目的成功與失敗其實跟耦合性有很大關係的。
隨著 USER提出的不同要求完成不同的功能，這本身就直接考驗著你的系統架構。 --------------------编程问答-------------------- 我想不仅仅是这些吧。。。。。 --------------------编程问答-------------------- 白盒测试 和黑盒测试 这是相关软件工程的 你看可以参看<<软件工程导论>>自己测试 也可请专门软件测试来测试
如果是项目的话 应该在分析项目的所有的图与理论 应该有专门机构 进行审核 测试也应该找呢个机构吧 --------------------编程问答-------------------- 现在 的话题是架构验证方法 而不是测试方法。。。。。 --------------------编程问答-------------------- 这个问题太大了，估计说不清楚。不过大家讨论一下对提高这方面的认识肯定是有帮助的。 --------------------编程问答-------------------- 不妨先讨论一下，什么是架构验证吧？在此基础上在深入讨论可能比较好一些。 --------------------编程问答-------------------- 通常是原型+渐进式交付
主要是让客户参与进来，让他知道你们设计成啥样了，现在做到啥样了-------别害羞，千万别害羞！丑媳妇还要见公婆呢，藏着掖着不是好习惯
至于架构，实际上最小原型就是原始架构，这个原始架构一开始就应该让客户参与进来，而不是等到尘埃落定，好啊歹啊都是他的时候才让客户去看
--------------------编程问答-------------------- 10楼说的有点意思了。不过还是不太明确。。。。
真的是这样的吗？ --------------------编程问答-------------------- 继续顶~！继续关注！
架构设计的牛人出来讨论下吧。。。
本人不算牛人，但是还是有点‘牛’气的。。。 --------------------编程问答-------------------- 我顶！！ --------------------编程问答--------------------
小项目这样做做是可以的(这是比较典型的agile development methodology)，大项目这样做应该不行吧。 --------------------编程问答-------------------- 继续顶。。。。。。 --------------------编程问答-------------------- 顶！！！ --------------------编程问答-------------------- 别沉下去啊。。继续顶！！！！ --------------------编程问答-------------------- 架构的验证国际上也有一些方法和理论。（英文的，年纪大了记不住了：））
但话又说回来架构是很难验证的。因为架构师本来就是对整个系统最熟悉的人或是人群（必段完全了解需求），同时在技术上也是较为扎实的，
可以当做软件技术行业金字塔尖的人物。
但是有一点是可以明确的，架构是为了能让软件有更好的扩展性，也就是实现所谓的 “高内聚 松耦合”。
那么一个简单的方法就是，看你的需求，那些是变化的那些是相对稳定的。
而这个架构能否很好的适用这种变化，从而在新的需求或扩展到来时能给项目的维护或升级带来更小的代价。
再说，没有绝对好了的架构，其实架构也需不断地重构。
非牛人，愚见耳。 --------------------编程问答-------------------- showjancn
谢谢你的回复。。。感觉你思想也很超前了。。。
不过还是感觉不是我想要的。。。继续关注。。。。
牛人来啊。。。。。 --------------------编程问答-------------------- 继续顶！！！牛人来啊。。。。。 --------------------编程问答-------------------- 唉，
现实当然，又有多少项目是那么高可扩展性，又有几个项目需要花那么大的精力在架构上折腾。
真那么想折腾去买本架构师的书看看 --------------------编程问答-------------------- 借学！ --------------------编程问答-------------------- 顶！！！
来牛人。。。别沉了。。。。 --------------------编程问答-------------------- 别老师借学了。。。。要有内容。。。
说说自己的看法吧。。。 --------------------编程问答-------------------- 继续顶！！别沉了。啊。。。 --------------------编程问答-------------------- 说说自己的观点，大大小小接触过不少的项目。
项目的架构，在设计阶段，基本上都是“没有问题”的，甚至很多人会觉得很完美。
也正是因为“完美”，才能跟客户交差，否则你自己都觉得有问题，那客户怎么肯接受呢。
而绝大多数客户是不了解架构是什么东西的，他们关心的更多的是功能（我们且不说成本这个话题）
所以只要你能把他的功能又快又好的实现出来，他才不管你是什么架构架构，什么模式。
架构的好不好，其实在开发阶段就能不断体现出来。
一些日常的测试方法是测试不到架构的，但是也能体现出一些端倪。特别是性能方面的。
我觉得以下几个方面可能去注意：
1：你的架构能否应对客户层出不求的需求变化
不要说需求的变化是因为调研不充分之类，变化总是有的，而且有时候会不少，
特别是一些保险金融的，比如证监会或者保监会下了一个文，你的业务很可能会去改，
这部分虽然可以算是新的需求，但是尽量不要去推翻了现在的重做
2：你的性能是否能达到预计的水平，并且有冗余
开始的时候，数据量和并发量都很难达到实战状态，当用户的业务量不断扩大，数据量增大，操作员（网站访客）增多的时候
是否能简单地通过纯硬件增强就能扩展，而不用再去优化这优化那，找性能瓶颈
3：如果你的架构中，采用了第三方产品，你是否考虑到第三方产品可能会对你的架构带来影响
当然，这个说得也比较宏观了，还有很多细节方面
我觉得越大的项目，越讲究阶段性验收，一次性地验收，对双方风险都很大。
而客户的负责人员，也需要一个阶段性的成果，来提升自己的“政绩”。
架构的合理与否，成功与否，不是项目交互了就算成功了的，要在客户经过一段时间运营后才能真正体现出来。
当然，它在开发阶段就有的具体的表现的。 --------------------编程问答-------------------- 我比较认同26楼的说法.
何为构架,其实我也不知道了.
你的项目是否很有条理性,能否完成客户的初期预计的目的.对于客户在使用提出的一些不足,改进.你的架构是否能很好的支持并扩展性.
如果你满足了.客户所需要的功能,性能,安全,以及后期的一些扩展,允许一些需求变更,那这个架构就很OK了.你还要验证什么呢?
客户首先关心的就是功能,一般客户的逻辑能力不是很强的,他没办法用逻辑思维来想像软件中的东西.只能是很直观的看到已有的功能以及不足的功能.
再一个就是看你的性能.
如果架构用错了,最多在项目快结束时就会发现了.如果一定要去验证架构还不如去验证你的需求.如果你对你的需求了解很充分,对于这个项目未来的扩展方向也很有把握,那你的架构就不会有什么错误了.(当然经验很很要哦!) --------------------编程问答-------------------- 继续顶！！！高手出招。。阿泰都来了。。。支持。。。。 --------------------编程问答-------------------- 正如“阿泰”所说，架构在初期可以说是完美的。
当是大家可能存在一点误区，总以为架构的验证很需要用户。
但我个人认为，架构验证对用户要求并不很强烈，因为用户主要是需求进行评估与核实。而这个过程应该发生在架构设计之前或是在
设计架构视图中的用例视图时所要用到的。
需要明确的是而在架构设计出之前，需求应该是明朗的即《需求规格说明书》是成形的了。
当然除了架构设计中的用例视图与用户有关，部署视图也可能与用户有关联。但开发视图和进程视图
（RUP 4+1）或模块型视图、数据模型等与用户就没多大关系。
说远了，关键点：架构的验证。
架构的验证，目的为了验证我的架构能否真正被开发人员打造成可应用的软件系统。
常用的架构验证方法有：原型验证和Framework验证。
原型验证，前面有大侠也说过。但我认为其目的是为了验证那些风险极强的场景能否最终被实施。举个例子吧：你有个BS程序，某个
页面有大量的数据交互，你可能就要验证一下其效率，而后决定是否在架构中引入缓存机制？。
而Framework验证，则主要是去验证一点框架是否能满足你的设计。比如中间件的功能与性能,或是微软Entity framework的性能等。
你总不会在Wince中采用类似于Entity framework这样的技术吧（目前），但是就是采用了，光从架构上来看是看不出问题的，但是
一运行你可能会出现系统超慢。 --------------------编程问答-------------------- 继续顶！高手献身！！！！ --------------------编程问答-------------------- 没听说过有架构验证的
只知道有实践验证
做好以后就拿例子去验证
要不就是我个人知识太少了！ --------------------编程问答-------------------- 所以一个大项目，应该不是一年两年就行了的
长年累月的
--------------------编程问答-------------------- 这点分，那些高手可不愿意哦，楼主也太吝啬了哦 --------------------编程问答-------------------- 除了架构中的成本考虑需要客户参详,至于性能和可扩展性还是架构师自己在评估考量吧. --------------------编程问答-------------------- 架构是靠时间来验证的...
能够适应不同需求及需求变化的架构是理想化的，成熟稳定、可重用性较高、TCO较低的架构就是好的架构...小平同志说，管他黑猫白猫抓住老鼠就是好猫...
传统的手段是在编码阶段，或者等项目完成了通过实践来验证架构的合理性。但是这样如果架构被验证为失败，那么整个项目也就失败了。
--------------------------------------
这个问题说明你的项目没有经过立项验证，你们的项目管理有问题...初期的验证是通过提出几种较合理的架构综合评估...这个没什么标准，就是用排他法挑出一个相对成熟稳定合理的方案并持续完善... --------------------编程问答-------------------- 继续关注！！！！老鸟快来。。分数不多，但是问题很严重！！！ --------------------编程问答-------------------- 这么多的星星拉。。喜欢。。。 --------------------编程问答-------------------- 架构？ 关键是看需求和成本的，话说多少钱干多少活。为啥要说成本，通俗点,你不能指望十块钱能把普通PC变成超级服务器,上网本变成高端笔记本吧。
一般都是先验证这个架构是否满足成本，是否满足基本需求。为第一考虑要素的，扩展性等是最后考虑的卖点。
软件开发也是一样的，开发成本、维护成本这些也是架构需要考虑的事情。验证架构都是经验活，至少都有成功模型示例的。
空谈验证架构是无用的。
这类东西需要理论也需要经验，更需要时间去实践。 --------------------编程问答-------------------- 各有千秋，百花齐放 --------------------编程问答-------------------- 顶起
--------------------编程问答-------------------- ding --------------------编程问答-------------------- mark --------------------编程问答-------------------- 继续关注！！！狂顶！！！！
高手来支招啊。。。。。。。。老孟我对你真失望，都不来。。！！！！
周公。。我真想揍你！！！出来啊。。。！！！！！
。。。。。。。。 --------------------编程问答--------------------
我晕。。小心你被群殴啊~~ --------------------编程问答-------------------- 前期工作不做细做扎实，架构就已经出现问题了 --------------------编程问答-------------------- 架构是通过项目来验证的，没经历过三个以上项目考验的架构，不能算成熟、合理的架构
架构师的价值就体现在他们能够提供的合理的架构，保证项目的成功
要想提高项目成功率，其实平时就应该有这方面的积累，不断得拿一个小项目去验证和测试、完善架构
靠临时拍脑袋、开会讨论，是不会有什么太好的结果。 --------------------编程问答-------------------- 我再顶！！别沉了。。。 --------------------编程问答-------------------- up --------------------编程问答-------------------- 继续UP！！高手来啊。。。。 --------------------编程问答-------------------- 有没有什么关于.net的架构书籍可以阅读一下。 --------------------编程问答-------------------- 架构能验证，还要架构师干嘛
有很多项目是敏捷开发
ls说的原型+渐进式交付就是敏捷开发
原型->确认->修改原型->确认->。。
需求改变很可会会改变流程，而改变流程可能会改变架构的细节，甚至推倒一部分重来的风险也有
客户的初期需求是不可靠和模糊的，在这基础上堆砌起来的一切都是不可靠的
中国还是管理混乱，手工随意性大的中小型企业居多，国情，没办法
能让你理顺管理还好，有的客户自己管理不想理顺也不想按照你的建议，但什么都想实现的也很多
如果一开始用很成熟的大的架构，但客户出的钱很少，完全是赔本赚吆喝，成本太高，
而一开始用简单的架构，可能随着客户需求的升级和增加投入的资金，可能会选更好的架构
反正，架构这种东西在国内如果是做定制系统，是行大不通的，只能是敏捷开发，
研发自己的产品，定位客户群，倒可以考虑下架构问题
或者是大公司的大型项目，有良好公关的政府项目，公司有主导地位，或做不损害底层员工利益，不怕客户刁难的软件，
我想，才可能在架构什么的问题上自己说了算吧
我不知道自己还是不是在谈架构了。。好像有点跑题了。。
--------------------编程问答--------------------
LZ,说实话你的问题太难回答了。我估计越是高手越是费劲
三言两语无法说清楚，估计让高手给你解释好了，我们整理下就可以出本书。
小菜无能为力，帮你顶下。看有没有有空的高手了 --------------------编程问答-------------------- 顶我也非常非常想知道！！！目前做了好多项目不知道怎么来验证呢 --------------------编程问答-------------------- 我写过程序，我没接触过架构。呵呵。 --------------------编程问答-------------------- 问这样的问题 最好不要去做架构，出问题的可能性很大！架构是宏观概念，具体问题具体分析。不是在微软的架构就合适在3-5人团队中使用。合适才是最好！脱离具体的环境具体的问题空谈，架构好不好不是有意义的事情。 --------------------编程问答--------------------
Lz提的问题太飘渺，已经上升到哲学高度了。
传说金字塔架构非常完美，完美得中间没有一丝裂隙（一根头发丝也难以插入）。
但如果没有那么多不辞辛劳的苦工做完一块块完美的基石并推到合理的位置，这个塔是否能够存在？这个塔是否还能经受岁月的摧残？
PS:你有空来这里顶贴，还不如自己去验证每一个节点的压力极值和可能存在的问题。 --------------------编程问答-------------------- 顶！！！高手来了就好。。。
期待你们都来发言！！！ --------------------编程问答-------------------- up一下
不过楼主的分给的是少了点，高手们都不乐意来 --------------------编程问答-------------------- gaoshou ......高手不会都是冲分来的吧。。。。。
太吝啬了吧。。。。
切！ --------------------编程问答-------------------- Microsoft Visual Studio本身可以对解决方案的架构进行分析..有了分析数据,从你"架构的初衷"来审定是否达到你的预期要求...架构是因需求而定的,没有所谓的完美架构,所谓"完美架构",只不过是在一个"大众需求"上的"最佳方案"而已.与架构有关的需求就比较广了,通俗的如"方便升级."专业一点的如"接口\耦合度\移植性".
Microsoft Visual Studio对一个解决方案的度量:
--------------------编程问答--------------------
jixu ding !!!SP123我期待你来。。。周公。。。孟子。。。。。
剪刀。。。来啊。。！ --------------------编程问答-------------------- jixu ding !!!
SP123我期待你来。。。周公。。。孟子。。。。。
剪刀。。。来啊。。！ --------------------编程问答-------------------- 帮你顶下 --------------------编程问答-------------------- 顶！！！！牛人都不出来。。。。真吝啬。 --------------------编程问答-------------------- 学习 --------------------编程问答-------------------- 顶！！！！！！！！！ --------------------编程问答-------------------- 继续顶！ --------------------编程问答-------------------- 继续顶！5555。。。。。。。。。。。。。。。。。 --------------------编程问答-------------------- 看了上面的回答, 很受启发啊
架构的验证也可以从两个方面来考虑
1, 从开发的角度出发, 如是否支持快速开发、后期的扩展性（新业务的增加）等角度
2, 从完成之后的系统出发, 正式交付之后，应该从系统的稳定性、系统的执行速度等方面进行考虑了
但也要考虑框架的适用性，选择合适的框架，也就是说什么样的项目选择什么样的框架 --------------------编程问答-------------------- 看来构架这个词对于做产品的或做项目的有着不大相同的意义。 --------------------编程问答-------------------- 学习下.路过阶段 --------------------编程问答-------------------- 终于看完了，，只是来学习的 --------------------编程问答-------------------- 问专家至少要给100分滴。问4个专家得要400分。
当然，要是你跟专家熟，另说……
--------------------编程问答--------------------
"这个问题很严重"这个问题不是以分来衡量的，是以兴趣为基础，感兴趣的可以来交流一下，继续学习大家的观点。 --------------------编程问答-------------------- --------------------编程问答-------------------- 需求决定构架 --------------------编程问答-------------------- 架构的看实际的需求 --------------------编程问答-------------------- 哈哈。。。。我的帖子被推荐了。。。。
呵呵。。第一次哦。。。 --------------------编程问答-------------------- 就是有点可惜，我提过的人没有一个来过。。。。。
大灰狼可是我朋友，都不来。。。。气愤。。。。。 --------------------编程问答-------------------- 沒有定論! --------------------编程问答-------------------- 其实也不是那么回事，架构是根据需求来的，需求什么，就和什么最相关的架构 --------------------编程问答-------------------- mark --------------------编程问答-------------------- 学习 --------------------编程问答-------------------- ding --------------------编程问答-------------------- 整理客戶的問題，設計一個計算機原型來解決客戶問題。
進行編程前，需要進行原型合理評估(或者說是驗證)，以確認是否可以解決真正的問題。
一般設計一架飛機，都要經過理論驗證，然後才付之實現，就算是這樣也常有失敗。通過實踐驗證理論，再修正設計，慢慢走向成功。飛機框架需要滿足很多要求，它往往是多次試驗後得出的，而不是一次就能設計成形。
我們的程序框架，同樣不會是一次設計成形的，它需要滿足迭代上升的需求，一般情況下程序框架可以視作一組解決問題的程序容器，各種問題在框架內得以方便重用，新的問題可以放入框架中處理，並和舊問題良好兼容。
客戶的實際問題可以視作一個模型，一般我們用分治法，將客戶的實際問題分解成一個個小問題，將這些小問題組合在框架中，從而解決實際問題。框架作為問題的容器，它有很強的兼容能力，同時還有很強的組合能力，這樣才能解決比較多的實際問題。
當設計一個小型框架的時候，清楚它是用來做什麼的。什麼樣的問題在該框架中不好處理。什麼樣的問題可以良好處理，什麼樣的問題可以很快處理，什麼樣的問題不能處理，什麼樣的問題需要擴展處理。弄清楚框架的特性後，就知道如何評估(驗證)一個框架了。例如說：MS SQLServer , 什麼樣的問題可以用SQL 語句解決，什麼樣的問題在客戶端解決比較好，什麼樣的問題使用觸發器，什麼樣的問題使用CLI....清楚這些問題，就知道在SQLServer框架下能否解決客戶的實際問題。當你設計一個框架時同樣要考慮很多問題，同樣它不是一開始就是完美的，它是迭代發展起來的。
--------------------编程问答-------------------- 终于看到底了，也学习了一下！
mark --------------------编程问答-------------------- 路过的，学习了... --------------------编程问答-------------------- 看了这么多,无外乎就是在功能和性能二方面来验证.
功能方面是看看你的架构是否符合需求,满足客户的需要,完成客户要求的流程,对流程的扩展性表现的如何,即:改变需求或者改变流程你的架构是否要改动.是否易于将系统的功能模块分配给不同的开发人员,局部功能不能工作是否影响整个系统稳定工作,具有自我修复.
性能方面是首先还是要满足需求.评估一下在一些极端情况下,你的架构能否经得住测试和考验.
下班了,,新人愚见........... --------------------编程问答-------------------- 学习了 --------------------编程问答-------------------- 架构还是构架?构架还是设计?
模糊一片...... --------------------编程问答-------------------- 这个问题太复杂了，一两句话很难说清楚 --------------------编程问答-------------------- 架构往往在第二次开发才体现出好坏. --------------------编程问答-------------------- 学到不少 --------------------编程问答-------------------- 哈哈，最好的验证办法！
就是把它交给所有程序员用，看他们如何评价！
如果他们都说简单易用就绝对没错，如果抱怨很多，那是你的问题！
这是衡量软件架构的最好的办法！
谈用户体验是扯蛋，用户那能体验到你什么技术！
用户能够体验到的就是一个功能模块你们怎么这么快就搞定了，而且测试基本无技术问题！
好的架构的标准：
1. 简单易用，结构清晰。一看就明白，让人感觉怎么这么简单。
2. 要屏蔽掉所有会导致严重错误的代码让程序员在功能代码中去写。
3. 用起来容易，测试起来要更容易。
4. 扩展，维护及运行时管理，让人感觉非常轻松简单。
哈哈，多谢批评指点！
我喜欢简单实用的东东，一直坚守简单易用的设计原则，很多时候都会折中选择一些东西。 --------------------编程问答-------------------- mark --------------------编程问答-------------------- 构架之初是不太容易验证它的合理性的，本人私下认为，应该把精力放在可扩展性和冗余这两方面。如果这两方面做到了，即使构架不是很合理，也可以使用很低的成本就把它修正。 --------------------编程问答-------------------- 一堆什么人在说话？好像都是说的程序的架构啊，不是指产品的架构啊？？？为什么总是看不远，局限在编码阶段？？一个好的架构不是架构师一人说了算的，要经过多次，多人的REVIEW才行。中国人都是替别人卖命的货（呵呵，我也是中国人），只会编码，只想编码，要不就弄个方便编码和实现的架构。我想楼主就是这个意思吧。
架构再好，错误一堆，就不能算是产品。架构再烂，没有BUG，就是一个好的产品。不要再一味的追求技术，而要把精力花品质管理和控制上，才是正道。 --------------------编程问答-------------------- 我顶！！！大家都牛。。。 --------------------编程问答-------------------- 单从验证角度来看，设计是无法量化的验证的，而且每个设计都有优缺点，能适应需求变化、易维护、模块化程度高的设计就是好的设计。
评审是为设计把关的重要环节。 --------------------编程问答-------------------- 还有，一次到位的设计是不存在的，反复修正是必需的。所以不要在项目开始时就追求最完美的设计。
补充：.NET技术 , C#
