许多开发认为架构设计离自己很远,其实架构设计的思想体现在方方面面。大到系统的设计,模块的划分,中至模块内工程的组织,jar包的组织,小至工程拆分成几个类,每个类包含哪些方法,这里面都蕴含和架构设计的思想。设计模式就是小层次的架构设计,利用前人的经验,组织自己的代码。之前看到好多人吐槽设计模式,认为毫无用处。个人认为,设计模式是很好的实践,设计模式的存在是为了更好的拥抱变化,在增加新功能时能够更加容易,另外,也作为沟通通用语言存在,彼此交流时直接说设计模式的名字就可以了,而不用大段的描述如何实现。
架构设计的目的是为了实现客户的需求。因此,关键需求决定架构。注意这里的关键二字,架构不是理想模型,要有可行性,所以架构不会面面俱到,会有取舍。架构不是毫无依据的设计。另外架构也是受需求影响一步一步演化来的。很多时候我们容易忽略实际的业务场景而进行架构的设计。这样就可能会变成“炫技”。架构并不是用的技术越超前越好,而是最适合最好。拿电商网站来说,在最初阶段,最紧迫的是快速上线,快速拿到用户的反馈,进一步完善网站。如果上来就前后端分离,划分微服务,采用分布式,数据库读写分离,分库分表,这样就是导致上线延迟,而且上线后并不知道效果如何,很有可能会黄掉。之前见到过有电商网站,开发了两年还没有上线,等到上线时,早就被其他人抢占了市场,后面不了了之了。
关键需求设计哪些维度?
1.关键功能。关键功能是我们系统所要具备的功能,如果没有这个功能,我们的系统就没有意义存在。比如电商系统里面的下单购买,如果不提供这个功能,其他功能设计的再好又有什么用呢?
2.关键质量。关键质量包括可用性、可服务性、可扩展性、性能等等。这部分是我们在设计的时候经常会忽略的东西,但是却是一个系统的核心竞争力。体验不好、性能慢的系统,肯定是要被淘汰的。质量属性之间往往是互斥的关系,不可兼得。比如扩展性可能会影响性能。为了找到系统的关键质量,需要立足业务,做取舍。很多时候架构设计也是一个取舍的过程。为了满足需求,做取舍。
3.约束。所谓约束就是系统存在的环境,包括运行环境,linux或者Windows,开发人员的素质等。开发需求一定要立足这样的事实。如果忽略这些因素,很可能造成需求的返工。
不同需求对架构的影响
在架构设计时要综合考虑这三个维度,发现隐藏的需求,避免遗漏。在需求设计时要首先把需求的范围确认清楚,如果有遗漏,在需求开发完后就很难再调整了,这时很可能就是要推倒重新设计,浪费人力和时间。
留言与评论(共有 0 条评论) |