不论是开发人员还是架构师，咱们都始终在跟软件系统打交道，架构是在工作中呈现最频繁的术语之一。那么，到底什么是架构？你可能有本人的答案，也有可能没有答案。对“架构”的了解须要咱们一直在实践中思考、演绎、演绎，造成本人的认知。
1 到底什么是软件架构？
定义”架构是什么“是件十分艰难的事件，不同的组织对于软件架构有不同的定义，每个人心中也有本身对于零碎架构定义的认知。就好比咱们无奈百分之百表述模型而只能产出模型不同维度的视图，对架构进行齐备的定义是不可能的。
“道可道，十分道。名可名，十分名”。
行业内不同的组织和集体从不同的视角对“什么是架构”进行了定义或论述。
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 认为软件架构是：重要并且难以扭转的决策。架构设计是对于衡量的艺术，架构设计过程中充斥了各种各样的决策，这些决策也终将反馈零碎架构。
Software Architecture = Important and hard to change decisions —Martin Fowler
而 Ralph Johnson 则对架构有更加“泛化”的定义 ： 软件架构就是重要的货色，不管它是什么！
The software architecutre is the important stuff ! Whatever it is ! —Ralph Johnson
以上的定义从高层形象视角对什么是架构给予了本人的答复，相比之下，Neil Ford 从架构组成元素动手，从更偏差实际的角度对架构进行了论述。核心思想是软件系统的架构包含以下组合元素：
•构造：利用零碎所抉择的架构格调，比方微服务架构、单体架构还是 SOA 等
•架构属性：零碎的非功能性属性，比方性能、可用性、可维护性等
•架构决策：零碎设计过程中重要的架构决策
•设计准则：设计过程中的指导性准则
构造
构造是零碎架构的重要组成部分，其从宏观上表述了零碎的构造组成。架构设计的外围工作之一是为零碎抉择适合的架构格调。比方，架构师基于上下文的衡量，能够抉择模块化单体架构格调，也能够抉择微服务架构格调。
架构属性
架构属性亦称品质属性，或非功能属性，通常示意零碎须要具备或满足的某种“能力”，比方高性能、可扩展性、弹性、伸缩性、容错性、可测试性、可维护性等等。架构设计的指标须要关注零碎须要满足的架构属性，架构最终要体现对架构属性反对的相干架构决策。架构属性泛滥，零碎须要关注的是这些架构属性的子集，具体的某次特定的架构设计所须要关注的架构属性须要根据问题域的上下文而具体分析 。同时，不同的架构属性间可能存在抵触，这种状况同样须要架构师的 衡量和决策。
架构决策
架构决策是零碎架构设计过程中对解决方案的抉择，其形容了 零碎必须遵循的规定 。架构决策随着衡量剖析而天然存在，其是零碎架构设计的重要维度之一。 并不是所有的决策都是架构决策，架构决策应该关注对系统有重要影响的局部。比方对架构格调的抉择对系统存在重要影响，其扭转的老本较高，理当属于架构决策的领域。比拟典型架构决策包含但不限于：
•间接影响 高优先级的架构属性
•批改对外接口：对外提供的接口批改往往须要进行充沛影响剖析
•引入或者移除依赖：依赖的退出和移除往往标示着组件能力的引进和废除
•扭转零碎的通用构造：工程构造是利用架构的重要维度之一
•迫使研发人员扭转开发方式
•承受战略性技术债：重构影响较大的技术债往往对现有零碎会有较大影响
注：架构决策倡议以轻量级的文档化模式进行记录，参考文章《轻量级的架构决策记录机制》一文
设计准则
设计准则与架构决策不同，其本质区别是：设计准则是一种领导，而非强制的规定。架构决策须要恪守，设计准则提供参考性指引。
比方，设计准则可能是：在可能的状况下，跨零碎间的通信尽可能应用异步音讯机制以进步性能和升高耦合。
以上对架构的定义各有特点：
•IEEE 定义更加结构化和规范化
•Martin Fowler 的定义偏重架构决策的重要性
•Ralph Johnson 则更加泛化，突出“重要”这一外围因子
•Neil Ford 则更具象化
我集体更偏向于Ralph Johnson 对于架构的抽象化定义，简略却不失对架构实质的论述，这也是我在工作中判断架构边界的准则之一。
2 架构设计的边界
如果你是团队的架构师，你是否有以下 困惑：
•零碎的架构应该设计到什么粒度？
•架构设计是否要足够具体以便能间接领导开发人员发展编码工作？
如果你是团队的外围开发人员，你是否 “ 埋怨 ” 过：
• “ 架构设计 ” 太过具体，涵盖了实现的“细枝末节”，本人除了 CRUD 没有施展的空间
• “ 架构设计 ” 太过宏观，基于设计方案根本无法领导开发，本人还得从新设计
很多架构师本身对架构和设计的边界不足深刻认知，相比于对架构边界的放大，更多时候 会呈现架构设计边界放大的状况：
架构师把架构设计当作具体的技术方案设计，牢牢把控系统实现的所有细节，产出大量的设计文档，而后交由外围开发人员做代码实现的执行工作。
这种景象会导致如下问题：
•压缩了团队外围开发人员的设计施展空间，不利于其技术水平及认知的晋升
•作为架构师你真的能讲所有的细节都 Cover 住吗？即便消耗微小精力实现了“齐备”的设计，来自一线开发所面临的各种场景是否可能提前预知和捕捉？
•如果需要迭代继续如此，作为外围开发人员多半会有所“牢骚”
•作为团队的架构师精力有限，继续的细节输入会消耗微小精力，而无奈关注更加宏观的层面
•…….
以上问题的本源是什么？不能明确架构设计的边界！
•架构设计与设计（实现相干）的边界或粒度问题
•团队架构师与开发人员间的职责边界
判断架构边界的前提之一是：明确架构和设计的关系！
所有的架构都是设计，但设计不肯定是架构！
从架构的定义看架构设计的边界，选取两个视角：
•架构是零碎中重要的货色！无论它是什么（之所以重要，是因为扭转的老本高）
•架构设计涵盖零碎中重要的架构决策
所以，架构设计应该涵盖零碎中重要的货色，这些“重要的货色”可能是：
•利用架构格调的抉择
•子系统间信息通信的形式
•工程采取的分层以及层间束缚
•工程应该遵循的开发标准
•工程引入的三方类库，或者三方框架
•高优先级的架构属性：比方某次需要建设十分关注零碎的性能，或者扩展性等架构属性
•其它 “重要的货色“
架构设计涵盖了零碎所需的重要的架构决策，从宏观层面对系统实现予以指引。而具体的设计则为具体的开发实现提供领导，比方，具体的 E - R 图设计、具体的代码级别的模式抉择、某个组件的具体实现等等。
架构不是变化无穷，须要继续演进，而实现相干的设计也可能在我的项目进行中继续变动，因而，二者不能齐全割裂，而是须要在实现过程中进行双向反馈：
•架构设计信息要高效的同步至开发人员
•实现过程中的变更同样也要回向反馈至架构，以便对架构设计进行调整
在进行架构边界断定时要留神一个至关重要的因子：上下文！！！以上的判断准则必须要给定的上下文中才有价值。
比方：实现过程中大家常常会实用一些设计模式，例如策略模式。那么，这种设计模式的抉择是属于架构设计还是具体的实现设计？答案就是：It depends!!! 具体情况，具体分析。
如果以后上下文，咱们十分关注零碎的扩展性，该架构属性是咱们高优先级的架构属性，那么，外围模块的策略模式的利用能够看作是架构设计的领域。而如果上下文中扩展性不是咱们关注的高优先级的架构属性，相比咱们更关注性能，那么，这种代码级的设计模式抉择应该属于架构设计的领域之外了，而须要划分到实现设计层面，交由外围开发自主决定。
3 架构模式（Patterns）与架构格调（Styles）
架构模式 和架构格调 是极容易混同的两个概念，很多开发人员将其了解为同一事物，而实际上二者有本质区别。
•架构格调是 零碎设计的顶层形象，从宏观视角表述咱们的零碎组成。更进一步，架构格调聚焦于零碎的分层、模块以及交互模式。
•架构模式聚焦于对 反复呈现问题提供解决方案
二者概念不同，并不存在抵触，其分割如下图所示：
•架构模式能够利用于架构格调，在同一架构格调上下文内能够利用一或多种架构模式
•架构格调能够 组合 以产生新的架构格调
比拟典型的例子是CQRS：CQRS 自身是一种模式，将命令和查问的职责在不同维度进行拆散。该模式咱们能够在单体架构格调中应用，也能够在微服务架构格调中应用，当然也能够在 SOA 架构格调中应用。
4 为什么要做架构设计？
至于“为什么要做架构设计”也是一个古老且频繁呈现的问题，有太多的文章论述为社么要架构设计：有的宏观，有的具体，有的“求实”，有的“务实”。我把这个问题作为一个独立章节论述，并不是想进行大篇幅的阐述，只是想突出它的重要性，这个问题值得消耗一些精力去深刻了解其背地的起因。但，在此不做开展过多阐明，通过一句话来进行概括：
之所以要进行架构设计，是因为：重要！
•做，收益高
•不做，老本高
5 开发人员和架构师的常识模型
作为开发人员，更加关注常识的深度，以便有足够的常识储备满足工作须要。开发人员在职业生涯的晚期，应该关注于本身常识储备的增长，并放弃技术深度。
作为架构师，之所以技术的广度比深度更重要，是因为架构师的重要职责之一是 进行架构决策。零碎架构设计是对于衡量的艺术，在特定的问题域上下文下，架构师须要在诸多可行的解决方案间进行衡量和决策，这也对其技术广度提出了要求。开发人员成长为架构师，应该更加关注常识的广度，并在几个特定畛域深耕，以便有足够的常识撑持架构决策。
尽管开发人员和架构师在常识域的关注点上存在差别，但在 认知层面都能够对立到 Bloom 认知层次模型。该模型将认知档次划分为逐渐递进的六个档次：
•识记：辨认和回溯事实性常识
•了解：了解事实的外延
•利用：将事实、规定、概念、思维加以利用
•剖析：将信息合成、关联、辨别、试验、测试
•评估：将信息或思维的价值进行评估
•发明：整合不同的信息造成新的常识体系
不论是架构师还是开发人员，Bloom 认知层次模型都实用。通过一直的学习扩大本身的常识体系，在识记、了解和利用的同时，要继续的造就剖析、评估和发明的能力，逐渐向高层次的认知程度晋升。
但须要留神的是：常识不等于认知，防止陷入常识学习的陷阱。常识是有限的，没有人可能以无限的精力去学习有限的常识。不论是开发人员还是架构师，又或者其余角色，不应该只将精力投入在常识边界的裁减，而应该重视从常识到认知晋升的转变。
吾生也有涯，而知也无涯。以有涯随无涯，殆矣！已而为知者，殆而已矣！—-《庄子》
格物以至知，对表象一直的演绎、演绎直至事物的本象，探寻事物背地的法则，建设更高层的认知。这种认知档次由下及上的跃升有两种形式：
•悟：由外向外，通过一直积攒、继续思考，由质变到量变，直至“开悟”
•破：自内向内，高层次或不同的思维输出碰撞，减速认知档次的冲破
为学日益，为道日损。损之又损，以⾄于⽆为。⽆为⽽⽆不为。–《道德经》
6 结语
对架构定义的探讨实际上是一种奢侈的“格物”的过程，每个人都应该寻找本人的答案。跳脱对架构定义探讨的视线，大家的工作和学习何尝不是如此呢？！大道至简，必由之路，格物致知，与君共勉！
作者：倪新明