不论是开发人员还是架构师，我们都一直在跟软件系统打交道，架构是在工作中出现最频繁的术语之一。那么，到底什么是架构？你可能有自己的答案，也有可能没有答案。对“架构”的理解需要我们不断在实践中思考、归纳、演绎，形成自己的认知。
一、什么是软件架构
定义 ”架构是什么“ 是件非常困难的事情，不同的组织对于软件架构有不同的定义，每个人心中也有自身对于系统架构定义的认知。就好比我们无法百分之百表述模型而只能产出模型不同维度的视图，对架构进行完备的定义是不可能的。
正所谓，“道可道，非常道。名可名，非常名”。这也是行业内不同的组织和个人从不同的视角对 “什么是架构” 的定义或阐述。
下面是IEEE组织对软件架构的定义：
the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution --ANSI/IEEE
将系统架构定义为：架构是系统组织结构 + 组件及联系（组件间以及组件和环境之间） + 原则的组合。通过图形化的形式表述该架构定义如下图所示，这是一个非常简洁、概念清晰的定义，其言简意赅的表达了架构的几个核心要素：
系统的组织：表达系统的宏观结构
组件及联系：组件化的思维，同时突出了环境要素。组件表达了系统的模块化，组件相互之间及组件与环境之间的关联表达元素间的相互作用。
原则：用于指导设计和系统演进的原则
大师 Martin Fowler对于架构的定义有着更加简洁的抽象，Martin Fowler 认为软件架构是：重要并且难以改变的决策。架构设计是关于权衡的艺术，架构设计过程中充满了各种各样的决策，这些决策也终将反应到系统架构。
而Ralph Johnson则对架构有更加 “泛化” 的定义：软件架构就是重要的东西，不论它是什么！
以上的定义从高层抽象视角对什么是架构给予了回答，相比之下，Neil Ford 从架构组成元素入手，从更偏向实践的角度对架构进行了阐述。核心思想是软件系统的架构包括以下组合元素：
结构：应用系统所选择的架构风格，比如微服务架构、单体架构还是SOA等
架构属性：系统的非功能性属性，比如性能、可用性、可维护性等
架构决策：系统设计过程中重要的架构决策
设计原则：设计过程中的指导性原则
结构
结构是系统架构的重要组成部分，其从宏观上表述了系统的结构组成。架构设计的核心任务之一是为系统选择合适的架构风格。比如，架构师基于上下文的权衡，可以选择模块化单体架构风格，也可以选择微服务架构风格。
架构属性
架构属性亦称质量属性，或非功能属性，通常表示系统需要具备或满足的某种 “能力”，比如高性能、可扩展性、弹性、伸缩性、容错性、可测试性、可维护性等等。架构设计的目标需要关注系统需要满足的架构属性，架构最终要体现对架构属性支持的相关架构决策。架构属性众多，系统需要关注的是这些架构属性的子集，具体的某次特定的架构设计所需要关注的架构属性需要依据问题域的上下文而具体分析。同时，不同的架构属性间可能存在冲突，这种情况同样需要架构师的权衡和决策。
架构决策
架构决策是系统架构设计过程中对解决方案的选择，其描述了系统必须遵循的规则。架构决策随着权衡分析而自然存在，其是系统架构设计的重要维度之一。并不是所有的决策都是架构决策，架构决策应该关注对系统有重要影响的部分。比如对架构风格的选择对系统存在重要影响，其改变的成本较高，理当属于架构决策的范畴。比较典型架构决策包括但不限于：
直接影响高优先级的架构属性
修改对外接口：对外提供的接口修改往往需要进行充分影响分析
引入或者移除依赖：依赖的加入和移除往往标示着组件能力的引进和废弃
改变系统的通用结构：工程结构是应用架构的重要维度之一
迫使研发人员改变开发方式
接受战略性技术债：重构影响较大的技术债往往对现有系统会有较大影响
设计原则
设计原则与架构决策不同，其本质区别是：设计原则是一种指导，而非强制的规则。架构决策需要遵守，设计原则提供参考性指引。
