03-架构设计三原则

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/sunshineyang1205/article/details/88142050

本文是通过学习李运华老师的《从0开始学架构》课程的随笔
现在自己对架构云里雾里的感觉,结合工作中的实践,学习与总结,慢慢的,会有质的提升的。

架构设计三原则:适合原则、简单原则、演化原则

适合原则(合适优于业界领先)

将军难打无兵之战
罗马不是一天建成的
冰山下面才是关键
在项目管理中,项目启动、规划、执行、监控、验收的整个过程,我们需要整个过程中合理评估和知晓我们所拥有的资源,人力、物力、财力等资源,知晓并合理安排使用,那么输入和产出比应该是在可控范围内,风险也应该尽可能的会在可预知风险中。
架构设计也是如此,如今技术发展很快,各种架构框架层出不穷,不一定先进的就是我们应该选择的,不是全而大的就是我们团队需要的。
架构是需要资源支撑的(我们需要考虑人力、物力、财力等);架构是需要不断实践趟坑的,稳扎稳打通过实践不断积累演进;架构是需要业务支持的(量变会引起质变),当业务不断增长时,它会逼着你去做架构的调整及演化。

简单原则(简单优于复杂)

“复杂”在制造领域代表先进,在建筑领域代表领先,但在软件领域代表“问题”
复杂度的体现:
1、结构复杂性
(1)、2个、3个、N个组件,组件越多,就越有可能某个组件故障从而导致系统故障;
(2)、某个组件的改动,会影响关联的所有组件;
(3)、定位一个复杂系统中的问题总是比简单系统更加困难;
2、逻辑复杂性
单个组件承担了太多的功能
逻辑复杂度会导致软件工程的每个环节都有问题,如迭代、分支……。

软件设计产出投入使用后,需要不断的迭代变更(新需求等)、需要不断的修改。
如果简单的方案和复杂的方案都可以满足需求,最好选择简单的方案。

演化原则(演化优于一步到位)

对于建筑来说,永恒是主题,对于软件来说,变化是主题。

软件架构需要根据业务发展不断变化。软件架构设计类似于大自然设计一个生物,通过演化让生物适应环境,逐步变得更加强大。
起初设计出来需要满足当时的业务需要→需要不断在世纪应用过程中迭代,保留优秀的设计,修复不足和缺陷,改正错误的设计、去除无用的设计→业务发生变化时,需要对架构进行扩展、重构甚至重写,但有价值的经验教训、逻辑设计等却可以在新架构汇总延续。

合适优于业界领先→简单优于复杂→演化优于一步到位

没有更多推荐了,返回首页