说说自己的观点，大大小小接触过不少的项目。
项目的架构，在设计阶段，基本上都是“没有问题”的，甚至很多人会觉得很完美。
也正是因为“完美”，才能跟客户交差，否则你自己都觉得有问题，那客户怎么肯接受呢。
而绝大多数客户是不了解架构是什么东西的，他们关心的更多的是功能（我们且不说成本这个话题）
所以只要你能把他的功能又快又好的实现出来，他才不管你是什么架构架构，什么模式。
架构的好不好，其实在开发阶段就能不断体现出来。
一些日常的测试方法是测试不到架构的，但是也能体现出一些端倪。特别是性能方面的。
我觉得以下几个方面可能去注意：
1：你的架构能否应对客户层出不求的需求变化
不要说需求的变化是因为调研不充分之类，变化总是有的，而且有时候会不少，
特别是一些保险金融的，比如证监会或者保监会下了一个文，你的业务很可能会去改，
这部分虽然可以算是新的需求，但是尽量不要去推翻了现在的重做
2：你的性能是否能达到预计的水平，并且有冗余
开始的时候，数据量和并发量都很难达到实战状态，当用户的业务量不断扩大，数据量增大，操作员（网站访客）增多的时候
是否能简单地通过纯硬件增强就能扩展，而不用再去优化这优化那，找性能瓶颈
3：如果你的架构中，采用了第三方产品，你是否考虑到第三方产品可能会对你的架构带来影响
当然，这个说得也比较宏观了，还有很多细节方面
我觉得越大的项目，越讲究阶段性验收，一次性地验收，对双方风险都很大。
而客户的负责人员，也需要一个阶段性的成果，来提升自己的“政绩”。
架构的合理与否，成功与否，不是项目交互了就算成功了的，要在客户经过一段时间运营后才能真正体现出来。
当然，它在开发阶段就有的具体的表现的。
有很多项目是敏捷开发
ls说的原型+渐进式交付就是敏捷开发