软件架构设计思考之一 (转载)

架构设计,一直就是软件业界中显得高深的名词之一,会造成很多的人对于它都充满了神秘感,但接触过几年软件业的人很多时候又会觉得软件架构原来不过如此,特别是看到一些架构设计文档后更是得出如此的感想,但真的是如此吗?也许是因为那些架构设计文档并没有起到它们真正的作用,只是拿来糊糊人的吧,架构设计文档最重要的是要能对系统的软件设计做出指导,做出规范性的约束,不谈这些,重点还是谈架构设计。
首先我们想想为什么要做架构设计呢?可能很多人会说在他们的系统中就是没做架构设计的,但其实不管你有没有做架构设计,你的脑海中或多或少都是已经考虑过的,只是也许没有变的那么的正规,首先,我们来看看什么是架构,架构作为系统的骨架而存在,正因为这个原因才说所有的系统都是有架构的,有架构自然就有设计,尽管它也许只是浮在你脑海中的某个东西而已,从架构中我们可以看到对于整个系统的支持,包括系统的各个方面,业务需求、用户需求以及功能需求的满足,架构设计能帮助你站在高的角度来看待、分析整个系统,在架构设计中通常采用OOAD的方法来帮助完成架构设计,想想没有架构设计的系统是什么系统呢?是一个没有骨架的系统,一个人没有骨架会怎么样呢?那么,同样,一个系统呢?一个系统没有骨架甚至比一个人没有骨架更为严重。
那么我们怎么去做架构设计呢?架构来源于需求,是在对需求进行分析、设计的情况下产生出来的,一个系统的需求通常非常的复杂,那么怎么样去产生它的架构呢?我们知道软件设计中最重要的就是抽象,其实说的更为专业应该是采用OO的思想,在过去采用的是面向过程的思想,这里就不再去讨论为什么要采用OO了,OO中几个重要的思想就是抽象、继承、封装,在分析和设计时我们同样要进行遵循,分析过程是对需求进行分析,产生出概念模型,此概念模型和设计的模型是不同的,概念模型停留于业务层面,而设计模型则为对此概念模型提出技术级别的解决实现方案,在经历了分析、设计过程后我们的系统架构就得以诞生,系统架构作为系统的一部分,同样要面临需求变化所带来的影响,而同时系统架构作为系统最为基础的部分,是要尽量减少变化所带来的影响的,要解决这个矛盾,在做架构设计时就要多多的考虑,可以采用使用模式、接口化等多种方式。
大家也许也看出,在写这篇blog我表达的并不是很清楚,确实,因为我自己都还有不少迷惑的地方,虽然写过那么几篇架构设计文档,做过那么几次架构设计,但一直以来就觉得以前做的架构设计不是那么的到位,通常有些部分还是平白无故就诞生出来了,而这些主要是依据的自己的经验,而不是对需求的分析,这对于系统架构而言是致命的,觉得现在也是静下心来好好考虑的时候了,同时也会多多的参看架构设计理论方面的书籍,结合实践提升自己在架构设计上的水平,所以将这篇blog的标题定位了思考之一,在思考的有些进展的时候会将这个继续的写下去,也希望能得到更多的做过架构设计的同仁、前辈的指点。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值