结构是相关元素之间的组织和安排，它是一个很普遍的概念，我们无时无刻不在谈论着各种对象的结构，如：细胞结构、人体结构、目录结构、分子结构、组织架构、文章结构等等数不尽的结构。
那么，当人们用语言或图片向我们描述细胞结构、分子结构、软件架构时，这些符号想表达什么？
比如上面的两张图，植物细胞结构图能表达细胞的各个组成部分以及它们之间的关系；分子结构图能表达出它的组成成分原子以及原子在空间中的排列关系；
同样，软件架构图表达软件由那些组件组成以及它们之间的关系。
所以，我们可以看出当人们谈论对象的结构或软件工程师讨论软件架构时，他们想描述的是对象中主要的、重要的、高层次的要素以及这些要素之间的关系。
软件架构的定义众说纷纭，至今还未形成统一的定义，越是不确定，就越显得神秘，人们也就越趋之若鹜。
结构和架构有区别吗？如果没有区别为什么不用结构一词而用架构，如果有区别那区别是什么？
读者可以对比一下软件架构图和生物学、化学以及其它行业的对象的结构图，看看它们所描述的东西有什么区别，其实会发现它们所描述的都是对象由那些要素构成以及它们之间的关系，结构和架构在概念上没有本质的区别。
但我们还是可以发现一些细微的区别，我们可以对比一下细胞结构和软件架构，细胞的结构所指的东西具有固定性，只要我们了解过下次有人提及的时候我们能明确知道他要表达的东西；
而软件架构通常不具有固定性，其要素和关系都存在变化的可能，所以笔者认为架构作为名词的时候它和结构的含义是一样的，只不过架构是一种可能变化的结构。
当我们从宏观层面看时，组件是软件的最小构件，一个复杂的软件便是由相互关联的组件（模块、服务）构成的整体，那么软件架构设计所面临的一个问题便是：设计什么样的结构来组织各种组件，从而实现设计目标。
虽然软件的结构没有固定性，但是人们还是从长期的实践中，总结出了一些常见的、可复用的、稳定不变的结构即架构模式。
它们分别是分层模式、客户端-服务器模式、主从模式、管道-过滤器模式、代理模式、点对点模式、事件总线模式等。
软件除了具有宏观的结构即架构外，还有微观的结构即类与类之间的结构。
当我们从微观层面看时，在面向对象编程的程序中，类是软件的最小构件，一个复杂的软件便是由相互关联的类构成的集合，但这个集合中的类并不是孤立存在的，它们之间存在着6种基本关系：依赖，关联，聚合，组合，继承，实现。
类和类之间的关系会形成三种基本结构：一般具体结构、整体部分结构、组合结构。程序设计时，结构的好坏直接决定着程序的扩展性、灵活性、重用性以及复杂度。
所以，在长期的面向对象程序设计中，人们也总结出了一套可反复使用的设计结构，这便是GOF的23种设计模式如单例模式、工厂模式、代理模式等。
因此，我们可以看出结构之于软件的重要性就像建筑结构之于建筑物一样——如果一栋建筑物的结构无法承受正常的荷载作用那么它便有随时坍塌的风险，同样软件架构无法支撑业务发展，推到重构的现象在软件行业也是屡见不鲜的事了。
结构决定功能，这是一个重要的思想。当架构师针对某一重要问题提出解决方案后，他所思考的东西其实就是结构，他深知结构的重要性，他的职责是选择什么样的结构来组织解决问题的方案。其实，人人都是架构师，因为程序员也要思考如何组织类，只不过各自思考的元素的抽象程度以及重要程度有所区别而已，
架构师思考更抽象的、更重要的组件以及组件之间的关系，而程序员思考的是类以及类之间的关系。如果读者想成为架构师，那你首先想的不是需求如何实现，而是根据具体情况以及所要实现的设计目标确定好如何组织功能的结构，再去实现。
因为结构先行，可以让我们纵观全局，抓住主要的、重要的核心问题，不至于只见树木不见森林，深陷细节而无法自拔。所以，要善于利用结构，把它作为工具使用。
结构作为工具，它是一个能让事物变得井然有序的组织工具。有一种最常用的结构，它被广泛的用于人类生活的各个方面，这便是树形结构。
学生会使用它组织学科的知识点，软件工程师用它来组织代码，企业家使用它来组织员工生产。无论他们期望结构产生什么样的作用，但结构最基本的作用是让复杂的事物变得有序。
这正是所谓的无规矩,不成方圆，这里的结构便是规则或规定。如数据结构：数组、链表，语法结构：主谓宾、主系表，便是一种抽象结构，它们是一组规则或规定。
所以，我们可以看出架构既是结构也是规则、规范或规定，架构就是要让一切复杂的事物变得有序、简单、可理解。
总之，结构是对象中相关元素的组织方式，是人类的组织工具，也是规则。万物都有结构无论是空间结构、时间结构还是抽象结构，而且一个对象从不同的视角和关注点看会有呈现不同的结构。
软件结构具有层次性特征，层次越高，结构设计就越重要也越抽象，而且高层次的结构一旦确定就不易改变，如果要改变那么改变的成本就很高，所以显得结构设计的重要性。
