架构设计的 3 个原则(合适原则、简单原则、演化原则)

合适原则

合适原则宣言:“合适优于业界领先”。

真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的,能够合理地将资源整合在一起并发挥出最大功效,并且能够快速落地。

简单原则

简单原则宣言:“简单优于复杂”。

软件领域的复杂性体现在两个方面:

1. 结构的复杂性

组成复杂系统的组件数量更多;同时这些组件之间的关系也更加复杂。

2. 逻辑的复杂性

逻辑复杂的组件,一个典型特征就是单个组件承担了太多的功能。以电商业务为例,常见的功能有:商品管理、商品搜索、商品展示、订单管理、用户管理、支付、发货、客服……把这些功能全部在一个组件中实现,就是典型的逻辑复杂性。逻辑复杂几乎会导致软件工程的每个环节都有问题。原因在于一个软件系统在投入使用后,后续还有源源不断的需求要实现,因此要不断地修改系统,复杂性在整个系统生命周期中都有很大影响。

功能复杂的组件,另外一个典型特征就是采用了复杂的算法。复杂算法导致的问题主要是难以理解,进而导致难以实现、难以修改,并且出了问题难以快速解决。

演化原则

演化原则宣言:“演化优于一步到位”。

软件跟建筑不同需要根据业务的发展不断地变化!

考虑到软件架构需要根据业务发展不断变化这个本质特点,软件架构设计过程如下:

首先,设计出来的架构要满足当时的业务需要。

其次,架构要不断地在实际应用过程中迭代,保留优秀的设计,修复有缺陷的设计,改正错误的设计,去掉无用的设计,使得架构逐渐完善。

第三,当业务发生变化时,架构要扩展、重构,甚至重写;代码也许会重写,但有价值的经验、教训、逻辑、设计等(类似生物体内的基因)却可以在新架构中延续。

参考来源:极客时间

进行架构设计时不要贪大求全,或者盲目照搬大公司的做法。应该认真分析当前业务的特点,明确业务面临的主要问题,设计合理的架构,快速落地以满足业务需要,然后在运行过程中不断完善架构,不断随着业务演化架构。

即使是大公司的团队,在设计一个新系统的架构时,也需要遵循演化的原则,而不应该认为团队人员多、资源多,不管什么系统上来就要一步到位,因为业务的发展和变化是很快的,不管多牛的团队,也不可能完美预测所有的业务发展和变化路径。

猜你喜欢

转载自blog.csdn.net/haponchang/article/details/90482036