不论是开发人员还是架构师，我们都一直在跟软件系统打交道，架构是在工作中出现最频繁的术语之一。那么，到底什么是架构？你可能有自己的答案，也有可能没有答案。对“架构”的理解需要我们不断在实践中思考、归纳、演绎，形成自己的认知。
定义 ”架构是什么“ 是件非常困难的事情，不同的组织对于软件架构有不同的定义，每个人心中也有自身对于系统架构定义的认知。就好比我们无法百分之百表述模型而只能产出模型不同维度的视图，对架构进行完备的定义是不可能的。
正所谓，“道可道，非常道。名可名，非常名”。这也是行业内不同的组织和个人从不同的视角对 “什么是架构” 的定义或阐述。
下面是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 从架构组成元素入手，从更偏向实践的角度对架构进行了阐述。核心思想是软件系统的架构包括以下组合元素：
结构是系统架构的重要组成部分，其从宏观上表述了系统的结构组成。架构设计的核心任务之一是为系统选择合适的架构风格。比如，架构师基于上下文的权衡，可以选择模块化单体架构风格，也可以选择微服务架构风格。
架构属性亦称质量属性，或非功能属性，通常表示系统需要具备或满足的某种 “能力”，比如高性能、可扩展性、弹性、伸缩性、容错性、可测试性、可维护性等等。架构设计的目标需要关注系统需要满足的架构属性，架构最终要体现对架构属性支持的相关架构决策。架构属性众多，系统需要关注的是这些架构属性的子集，具体的某次特定的架构设计所需要关注的架构属性需要依据问题域的上下文而具体分析。同时，不同的架构属性间可能存在冲突，这种情况同样需要架构师的权衡和决策。
架构决策是系统架构设计过程中对解决方案的选择，其描述了系统必须遵循的规则。架构决策随着权衡分析而自然存在，其是系统架构设计的重要维度之一。并不是所有的决策都是架构决策，架构决策应该关注对系统有重要影响的部分。比如对架构风格的选择对系统存在重要影响，其改变的成本较高，理当属于架构决策的范畴。比较典型架构决策包括但不限于：
设计原则与架构决策不同，其本质区别是：设计原则是一种指导，而非强制的规则。架构决策需要遵守，设计原则提供参考性指引。
比如，设计原则可能是：在可能的情况下，跨系统间的通信尽可能使用异步消息机制以提高性能和降低耦合。
以上对架构的定义各有特点：
我个人更倾向于Ralph Johnson 对于架构的抽象化定义，简单却不失对架构本质的阐述，这也是我在工作中判断架构边界的准则之一。
如果你是团队的架构师，你是否有以下困惑：
如果你是团队的核心开发人员，你是否 “抱怨” 过：
事实上，很多架构师自身对架构和设计的边界缺乏深入认知，相比于对架构边界的缩小，更多时候会出现架构设计边界放大的情况：架构师把架构设计当作详细的技术方案设计，牢牢把控系统实现的所有细节，产出大量的设计文档，然后交由核心开发人员做代码实现的执行工作。
这种现象会导致如下问题：
以上问题的根源是什么？不能明确架构设计的边界！那如何解决这一问题呢？明确架构和设计的关系！
所有的架构都是设计，但设计不一定是架构！从架构的定义看架构设计的边界，选取两个视角：
所以，架构设计应该涵盖系统中重要的东西，这些 “重要的东西” 可能是：
架构设计涵盖了系统所需的重要的架构决策，从宏观层面对系统实现予以指引。而详细的设计则为具体的开发实现提供指导，比如，详细的E-R图设计、具体的代码级别的模式选择、某个组件的具体实现等等。
架构不是一成不变，需要持续演进，而实现相关的设计也可能在项目进行中持续变化，因此，二者不能完全割裂，而是需要在实现过程中进行双向反馈：
在进行架构边界判定时要注意一个至关重要的因子：上下文！！！以上的判断准则必须要给定的上下文中才有价值。比如：实现过程中大家经常会适用一些设计模式，例如策略模式。那么，这种设计模式的选择是属于架构设计还是详细的实现设计？答案就是：It depends!!! 具体情况，具体分析。
如果当前上下文，我们非常关注系统的扩展性，该架构属性是我们高优先级的架构属性，那么，核心模块的策略模式的应用可以看作是架构设计的范畴。而如果上下文中扩展性不是我们关注的高优先级的架构属性，相比我们更关注性能，那么，这种代码级的设计模式选择应该属于架构设计的范畴之外了，而需要划分到实现设计层面，交由核心开发自主决定。
架构模式和架构风格是极容易混淆的两个概念，很多开发人员将其理解为同一事物，而实际上二者有本质区别。
二者概念不同，并不存在冲突，其联系如下图所示：
比较典型的例子是CQRS：CQRS本身是一种模式，将命令和查询的职责在不同维度进行分离。该模式我们可以在单体架构风格中使用，也可以在微服务架构风格中使用，当然也可以在SOA架构风格中使用。
作为开发人员，更加关注知识的深度，以便有足够的知识储备满足工作需要。开发人员在职业生涯的早期，应该关注于自身知识储备的增长，并保持技术深度。
作为架构师，之所以技术的广度比深度更重要，是因为架构师的重要职责之一是进行架构决策。系统架构设计是关于权衡的艺术，在特定的问题域上下文下，架构师需要在诸多可行的解决方案间进行权衡和决策，这也对其技术广度提出了要求。开发人员成长为架构师，应该更加关注知识的广度，并在几个特定领域深耕，以便有足够的知识支撑架构决策。
虽然开发人员和架构师在知识域的关注点上存在差异，但在认知层面都可以统一到Bloom认知层次模型。该模型将认知层次划分为逐步递进的六个层次：
不论是架构师还是开发人员，Bloom认知层次模型都适用。通过不断的学习扩展自身的知识体系，在识记、理解和应用的同时，要持续的培养分析、评估和创造的能力，逐步向高层次的认知水平提升。但需要注意的是：知识不等于认知，避免陷入知识学习的陷阱。知识是无限的，没有人能够以有限的精力去学习无限的知识。不论是开发人员还是架构师，又或者其他角色，不应该只将精力投入在知识边界的扩充，而应该注重从知识到认知提升的转变。
正如圣人庄子所说：吾生也有涯，而知也无涯。以有涯随无涯，殆矣！已而为知者，殆而已矣！
格物以致知，对表象不断的归纳、演绎直至事物的本象，探寻事物背后的规律，建立更高层的认知。这种认知层次由下及上的跃升有两种方式：
对架构定义的探讨实际上是一种朴素的 “格物” 的过程，每个人都应该寻找自己的答案。跳脱对架构定义探讨的视野，大家的工作和学习何尝不是如此呢 ？！大道至简，殊途同归，格物致知，与君共勉！
