许多开发认为架构设计离自己很远，其实架构设计的思想体现在方方面面。大到系统的设计，模块的划分，中至模块内工程的组织，jar包的组织，小至工程拆分成几个类，每个类包含哪些方法，这里面都蕴含和架构设计的思想。设计模式就是小层次的架构设计，利用前人的经验，组织自己的代码。之前看到好多人吐槽设计模式，认为毫无用处。个人认为，设计模式是很好的实践，设计模式的存在是为了更好的拥抱变化，在增加新功能时能够更加容易，另外，也作为沟通通用语言存在，彼此交流时直接说设计模式的名字就可以了，而不用大段的描述如何实现。

架构设计的目的是为了实现客户的需求。因此，关键需求决定架构。注意这里的关键二字，架构不是理想模型，要有可行性，所以架构不会面面俱到，会有取舍。架构不是毫无依据的设计。另外架构也是受需求影响一步一步演化来的。很多时候我们容易忽略实际的业务场景而进行架构的设计。这样就可能会变成“炫技”。架构并不是用的技术越超前越好，而是最适合最好。拿电商网站来说，在最初阶段，最紧迫的是快速上线，快速拿到用户的反馈，进一步完善网站。如果上来就前后端分离，划分微服务，采用分布式，数据库读写分离，分库分表，这样就是导致上线延迟，而且上线后并不知道效果如何，很有可能会黄掉。之前见到过有电商网站，开发了两年还没有上线，等到上线时，早就被其他人抢占了市场，后面不了了之了。

关键需求设计哪些维度？

1.关键功能。关键功能是我们系统所要具备的功能，如果没有这个功能，我们的系统就没有意义存在。比如电商系统里面的下单购买，如果不提供这个功能，其他功能设计的再好又有什么用呢？

2.关键质量。关键质量包括可用性、可服务性、可扩展性、性能等等。这部分是我们在设计的时候经常会忽略的东西，但是却是一个系统的核心竞争力。体验不好、性能慢的系统，肯定是要被淘汰的。质量属性之间往往是互斥的关系，不可兼得。比如扩展性可能会影响性能。为了找到系统的关键质量，需要立足业务，做取舍。很多时候架构设计也是一个取舍的过程。为了满足需求，做取舍。

3.约束。所谓约束就是系统存在的环境，包括运行环境，linux或者Windows，开发人员的素质等。开发需求一定要立足这样的事实。如果忽略这些因素，很可能造成需求的返工。

不同需求对架构的影响

在架构设计时要综合考虑这三个维度，发现隐藏的需求，避免遗漏。在需求设计时要首先把需求的范围确认清楚，如果有遗漏，在需求开发完后就很难再调整了，这时很可能就是要推倒重新设计，浪费人力和时间。