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