软件架构设计思考

【IT168 技术文章】

    架构设计，一直就是软件业界中显得高深的名词之一，会造成很多的人对于它都充满了神秘感，但接触过几年软件业的人很多时候又会觉得软件架构原来不过如此，特别是看到一些架构设计文档后更是得出如此的感想，但真的是如此吗？也许是因为那些架构设计文档并没有起到它们真正的作用，只是拿来糊糊人的吧，架构设计文档最重要的是要能对系统的软件设计做出指导，做出规范性的约束，不谈这些，重点还是谈架构设计。

    首先我们想想为什么要做架构设计呢？可能很多人会说在他们的系统中就是没做架构设计的，但其实不管你有没有做架构设计，你的脑海中或多或少都是已经考虑过的，只是也许没有变的那么的正规，首先，我们来看看什么是架构，架构作为系统的骨架而存在，正因为这个原因才说所有的系统都是有架构的，有架构自然就有设计，尽管它也许只是浮在你脑海中的某个东西而已，从架构中我们可以看到对于整个系统的支持，包括系统的各个方面，业务需求、用户需求以及功能需求的满足，架构设计能帮助你站在高的角度来看待、分析整个系统，在架构设计中通常采用OOAD的方法来系统是什么系统呢？是一个没有骨架帮助完成架构设计，想想没有架构设计的的系统，一个人没有骨架会怎么样呢？那么，同样，一个系统呢？一个系统没有骨架甚至比一个人没有骨架更为严重。

    那么我们怎么去做架构设计呢？架构来源于需求，是在对需求进行分析、设计的情况下产生出来的，一个系统的需求通常非常的复杂，那么怎么样去产生它的架构呢？我们知道软件设计中最重要的就是抽象，其实说的更为专业应该是采用OO的思想，在过去采用的是面向过程的思想，这里就不再去讨论为什么要采用OO了，OO中几个重要的思想就是抽象、继承、封装，在分析和设计时我们同样要进行遵循，分析过程是对需求进行分析，产生出概念模型，此概念模型和设计的模型是不同的，概念模型停留于业务层面，而设计模型则为对此概念模型提出技术级别的解决实现方案，在经历了分析、设计过程后我们的系统架构就得以诞生，系统架构作为系统的一部分，同样要面临需求变化所带来的影响，而同时系统架构作为系统最为基础的部分，是要尽量减少变化所带来的影响的，要解决这个矛盾，在做架构设计时就要多多的考虑，可以采用使用模式、接口化等多种方式