理由如下:要说复杂度，我认为还是取决于业务，比如有的业务它并不需要高性能，比如特定公司的人群定制化使用的办公软件，只需要保障客户使用的时候不会出现一些功能方面的错误或者是业务方面的bug。
三、可扩展
可扩展性指的是应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无需整个系统重构或者重建。
回忆当初我们的PMS系统，为了实现某个功能，牵其一必动其余，那段心酸加班的苦日子，至今让我难以忘记。当然了，也许当初的考虑没有那么周到，写的代码也不够严谨规范，当然了，最重要的就是对业务不了解熟悉(犯了没有完全理解需求就直接开敲这样的错误，我想每个工作年限不长的人或者工作年限小于两年的都可能犯这样的错误)。
记得当初我还有一个这样的想法，幻想着将20多种设计模式全部应用到代码中，只要应用到代码上，代码质量、项目质量都会提高。不过，幸运的是我并没有那么做。
原因有这么几点?
(1)我自己对设计模式而言，仅仅只是知道它的名字，不知道它在实际的应用场景和怎么写的;
(2)由于(1)缘故，在我心中有这么个理念，没有把握的事情绝不干(虽然生活中干了不少没有把握的事情，比如曾经对某某一见钟情，就对其表白，最后的结果只能是以失败告终，如果结果对方同意，说明了两点，第一点，的确情投意合；第二点，这是一个陷阱)
(3)当时手里项目太多，由于之前系统遗留的问题，不停的解决问题，当然了，当解决以后，面对这么臃肿的项目，我只想说四个字(四个字是什么我就不说了，有些不文明)，不过的确面对一个很蛋疼的项目，要重构的话，不仅仅是时间问题，更重要是勇气，当然了，还有必不可少的筹备。
扯了一些相关又无关的话，下面进入正题说说。
首先有一个问题，什么才算是一个可扩展性良好的系统？可扩展性良好的系统具备哪些条件?
其实这两个问题可以理解为一个问题，不过我觉得还是分开说好一些，因为更全面。
针对第一个问题，我给出的回答是:
可扩展性良好的系统，用一句简单粗暴的话来说就是，面对产品经理变态的需求，你不需要内心暴打产品经理一百遍，不需要加班加点。一个字，就是“干”。这个“干”，不是之前痛苦的“干”，而是快乐的“干”。正常来说，之所以程序员对于产品经理抱着仇视的态度，关键不在于需求怎么样，而在于，实现这个需要需要改很多地方，改完很多地方，有可能又会出现新的问题，这才是最要命的。快乐的实现，在于将需求吃透的前提下，不需要改完这个改那个，只需在此基础上扩展就能达到这个目的。
我想如此，便是一个可扩展性良好的系统。
针对第二个问题，我给出的回答是:
一般在设计一个可扩展性良好的系统，需要具备这么两个基本条件:
(1)正确预测变化;
(2)完美封装变化;
关于(1)，软件系统与硬件系统或者建筑相比，有一个很大的差异:软件系统在发布后还可以不断地修改和演进，这就意味着不断有新的需求需要实现。如果新的需求能够不需要改动代码或者是少改动代码就可以实现，肯定是皆大欢喜的，否则来一个需要就要求系统大改一次，成本会非常高，程序员心里也不爽(改来该去），产品经理也不爽(做的那么慢)，老板更不爽(那么多人就只能干这点事情，要你们何用)。因此作为架构师，我们总是试图去预测这些变化，然后设计完美的方案来应对，当下一次需求真正来临时，架构师可以自豪地说:这个我当时就已经预测到了，架构能够完美地支持，只需几个小时就可以了(在团队成员眼里是多么牛逼的存在)。
有一句名言叫做:理想很丰满，现实很骨感。
在IT界中有一句谚语叫做:唯一不变的是变化。
这句话值得细细品味，比如如果架构师在每个设计方案都要考虑可扩展性，那么架构师会不堪重负，有一句话叫做，鱼和熊掌不可兼得。
另外关于预测，预测本身就暗示了不可能每次预测都是正确的(如果每次预测都是正确的，你可以去做预言家了)。
关于预测变化的复杂性，主要有这么几个体现:
a.不能每个设计点都考虑可扩展性;
b.不能不完全考虑可扩展性;
c.所有的预测都存在出错的可能性;