架构设计的高级问题 ！！！有请孟子，大灰狼，SP123等等牛人。

Question

架构无须验证，也没有办法直接验证。不管什么架构，如果在给定的时间和给定的费用内，完成了客户需求验证(业务功能实现、用户体验、性能和Availability)，那么就可以说这个架构是合理的。架构的验证是通过客户需求的验证来间接验证的。自己也觉得上面的话有失欲偏颇:) 大家批评指正！

Answer 1

好像隨著自己的不斷成熟，每個階段的架構都不太一樣的。其實一個大項目的成功與失敗其實跟耦合性有很大關係的。
隨著 USER提出的不同要求完成不同的功能，這本身就直接考驗著你的系統架構。

Answer 2

白盒测试 和黑盒测试  这是相关软件工程的  你看可以参看<<软件工程导论>>自己测试  也可请专门软件测试来测试如果是项目的话  应该在分析项目的所有的图与理论  应该有专门机构 进行审核  测试也应该找呢个机构吧

Answer 3

小项目这样做做是可以的(这是比较典型的agile development methodology)，大项目这样做应该不行吧。

Answer 4

showjancn 谢谢你的回复感觉你思想也很超前了不过还是感觉不是我想要的继续关注。牛人来啊。。

Answer 5

正如“阿泰”所说，架构在初期可以说是完美的。当是大家可能存在一点误区，总以为架构的验证很需要用户。
但我个人认为，架构验证对用户要求并不很强烈，因为用户主要是需求进行评估与核实。而这个过程应该发生在架构设计之前或是在设计架构视图中的用例视图时所要用到的。
需要明确的是而在架构设计出之前，需求应该是明朗的即《需求规格说明书》是成形的了。
当然除了架构设计中的用例视图与用户有关，部署视图也可能与用户有关联。但开发视图和进程视图
（RUP 4+1）或模块型视图、数据模型等与用户就没多大关系。说远了，关键点：架构的验证。架构的验证，目的为了验证我的架构能否真正被开发人员打造成可应用的软件系统。
常用的架构验证方法有：原型验证和Framework验证。
原型验证，前面有大侠也说过。但我认为其目的是为了验证那些风险极强的场景能否最终被实施。举个例子吧：你有个BS程序，某个页面有大量的数据交互，你可能就要验证一下其效率，而后决定是否在架构中引入缓存机制？。
而Framework验证，则主要是去验证一点框架是否能满足你的设计。比如中间件的功能与性能,或是微软Entity framework的性能等。
你总不会在Wince中采用类似于Entity framework这样的技术吧（目前），但是就是采用了，光从架构上来看是看不出问题的，但是一运行你可能会出现系统超慢。 

Answer 6

架构是靠时间来验证的...能够适应不同需求及需求变化的架构是理想化的，成熟稳定、可重用性较高、TCO较低的架构就是好的架构...小平同志说，管他黑猫白猫抓住老鼠就是好猫...
传统的手段是在编码阶段，或者等项目完成了通过实践来验证架构的合理性。但是这样如果架构被验证为失败，那么整个项目也就失败了。
--------------------------------------
这个问题说明你的项目没有经过立项验证，你们的项目管理有问题...初期的验证是通过提出几种较合理的架构综合评估...这个没什么标准，就是用排他法挑出一个相对成熟稳定合理的方案并持续完善...

Answer 7

有没有什么关于.net的架构书籍可以阅读一下。