“架构”（Architecture）的起源可追溯到修建职业。它的英文“Architecture”源自拉丁语词“Architectura”，进一步溯源则发现其底子来自希腊语“Arkitekton”（）。在这个希腊语词汇中，“”（Archi）表明“首要的”或“首要的”，而“”（tekton）意味着修建师或工匠。因而，“Arkitekton”直译为“主修建师”，提醒了“架构”一词背面的深层含义，指涉一种主导或中心的建设和创造人物。
1.1从修建到社会文明
修建，作为人类文明进步(如图1-2所示太和殿)的重要标志，与架构的概念严密相连，深化表现了人类社会开展的进程。在探求全球不同文明的前史进程中，无论是埃及、我国、印度、巴比伦、玛雅、希腊、苏美尔、印加还是波斯等古代文明，它们留下的雄伟修建遗产都见证了人类文明的光辉创造力和才智。
以奇琴伊察为例，这个坐落墨西哥尤卡坦半岛的玛雅城邦遗址，展现了古玛雅文明的昌盛与才智。这座城邦自公元514年建立起，成为古玛雅帝国中最具规划和繁华的城市之一，拥有杰出的艺术家、雕刻家、修建师、工程师和地理学家。奇琴伊察的首要古迹，如千柱广场、武士庙、库库尔坎金字塔和古地理观测台等，都生动展现了玛雅人在修建规划与空间运用方面的特殊才调。
修建不单是一种文明的表现，它还是人类最早构成完善理论和实践经历的范畴之一。前史上的文明社会在修建方面堆集了丰厚的风格、技能和工艺。特别是在古代，修建学的理论现已相当兴旺。如古罗马的修建师维特鲁威（Vitruvius）在其著作《修建十书》中提出，一个优良的修建应当具有三个底子要素：持久性、实用性和漂亮性。这三个原则不只影响了后世的修建规划，也成为衡量修建艺术的规范。
- 持久性（Durability） 强调修建的稳定性和耐久性。修建物需求饱尝时刻的检测，坚持结构的完整性和功用的持续性。这要求修建材料的挑选和修建结构的规划都有必要可以抵挡天然和人为的磨损，保证修建可以长久地服务于人类社会。例如，古埃及的金字塔、我国的长城和罗马的斗兽场，都是持久性原则的杰出代表。
- 实用性（Utility） 触及修建的功用性和适用性。修建物不只要满意人们的底子日子需求，还应考虑到运用的快捷性和舒适性。这意味着修建规划要充沛考虑空间布局的合理性、环境的适宜性和用户的体验，以保证修建在实际运用中的功用性和功率。例如，现代住宅和办公楼便是在实用性原则辅导下规划的，旨在为人们供给快捷、舒适的日子和作业环境。
- 漂亮性（Beauty） 重视修建的审美和艺术价值。一个美丽的修建不只可以提升周边环境的美感，还能激发人们的情感和创意。修建的漂亮性要求规划师充沛运用创意和艺术办法，经过修建的形状、颜色、材料和细节处理等元素，创造出既契合审美规范又能反映时代精神和文明特色的著作。例如，巴黎的埃菲尔铁塔、悉尼歌剧院和北京的国家大剧院都是漂亮性原则的典范。
在今世，架构的含义现已拓展，不再仅限于单一修建物或结构的规划，而是涵盖了从城市规划、都市规划到景观修建、修建细节乃至内部家具规划的整个范畴。这种广泛的界说反映了修建学作为一门综合性学科的丰厚性，以及它在推动人类社会文明进步中的中心位置。跟着时刻的推移，修建与架构不只代表了一种艺术和科学的结合，也成为了人类才智与创造力的标志。
1.2架构思维的跨范畴使用
在长期的修建职业实践中，人类堆集了很多的名贵经历和深化见地，这些不只在修建范畴内具有重要的辅导作用，也对其他范畴的人类活动发生了深远的影响。跟着时刻的推移和科技的开展，修建学中的“架构”概念逐渐演化，其含义和使用范围不断扩大，现已渗透到人类日子的各个方面。
几千年的修建实践为人类留下了丰厚的办法论、实践经历和教训，这些成果不只对今世的修建规划具有重要的实践辅导价值，更重要的是，它们现已逾越了修建职业的界限，为其他工程学科范畴供给了名贵的参阅和启示。这些经历和常识逐渐演化成一种固定的思维方式，成为了人类才智和创造力的重要组成部分。
当“架构”这个词从修建职业拓展到其他范畴，如生物工程、航天工程、地理信息体系等，它展现出了全新的内涵和价值。虽然范畴改动，但“架构”的内涵精华坚持了一致性，本质上仍然是对结构内部元素及其相互联络的一种主观了解和映射。修建规划中很多运用的空间、容量、纹理、光影、材料等元素，旨在保证规划元素之间在审美和功用上的调和统一，这种思维办法与其他工程学科中寻求功用性和结构优化的要求有着本质的相似性。
在计算机科学与工程这个较为年青的学科范畴中，虽然前史较短，人类以往在修建实践中堆集的经历和原则依然具有辅导含义。例如，咱们可以学习古罗马修建师维特鲁威提出的持久性、实用性和漂亮性三大规划原则来辅导体系规划。此外，修建职业的其他经历和才智，如路易斯沙利文的“方式服从于功用”原则，也为其他规划范畴供给了重要的参阅和创意。这些跨范畴的使用和学习，充沛展现了修建范畴经历和常识在人类社会开展中的广泛影响和深远含义。
1.3架构的构成
其实关于目前的记载，软件架构的详细起源现已很难被发现了，在1960年代，艾兹格迪杰斯特拉等开始触及软件架构范畴，从1990年代后，软件架构这个概念开始变得愈发盛行。而碰巧的是，1968年秋季，NATO科技委员会召集了一群优异的软件工程师，来脑暴“软件危机”的处理计划，也是在这次会议上诞生了Software Engineering概念，即软件工程。
1993年，电气电子工程师学会（IEEE）给出了关于Software Engineering的界说：“将体系化的、规范的、可度量的办法用于软件的开发、运转和保护的进程，行将工程化使用于软件开发中”。
软件工程是面向工程范畴的，软件工程包含软件架构的规划，而软件架构即是一张开发蓝图，是一个计划，是全体的规划，亦是软件工程的辅导方针。
2.1技能中的架构到底是什么
经过前面的介绍，咱们对架构的前史头绪有了一些底子的认识。咱们来深化考虑一下：这个常常呈现在各种技能谈论中的“架构”，到底是什么意思呢？
是的，咱们常常听到“架构”这个词，可是真实停下来考虑它的界说和内涵，你会发现不是那么简略。在技能界，尤其是软件开发范畴，“架构”简直成了一个时尚的词汇，人人都在谈论它，可是真实了解它的精华的人却不多。那么，什么是软件架构呢？它又为什么如此重要？
在咱们继续深化探求之前，让咱们首要澄清一下“架构”的底子含义。接下来的内容，咱们将从软件架构的界说谈起，探求它的中心组成部分，然后再进一步谈论它在软件开发进程中的重要作用和价值。这样，咱们不只可以更好地了解架构这个概念，并且还可以了解为什么它关于构建高效、可保护的软件体系如此要害。
2.1.1架构的诞生
在讨论软件开发的很多新办法和理念时，咱们发现“软件架构”的概念显得异乎寻常。不同于其他为应对新兴软件危机而诞生的理念，软件架构的呈现好像并不直接源于职业共面的某个特定问题。这儿面有何玄机呢？
跟着软件体系规划的日益巨大，一项明显的改动是，传统的计算算法和数据结构已不再是规划应战的首要焦点。在一个由很多部件构成的体系中，怎样高效地安排这些部件——即咱们所称的“软件架构”——成为了规划师们面临的一系列新问题。比方，你或许遇到如下应战：
- 体系规划巨大至必定程度，内部耦合变得反常杂乱，严重拖慢了开发功率；
- 由于部件之间的严密耦合，对体系的任何细小修改都或许引发连锁反应，使得后续的保护和扩展作业变得反常困难；
- 杂乱的体系逻辑使得问题频发，一旦呈现问题，定位和修正的难度极大。
在这样的布景下，“软件架构”的概念应运而生，其前史位置和必然性不言而喻。回望过去，咱们可以发现，榜首次软件危机推动了“结构化编程”的开展，带来了“模块”的概念；随后，第2次软件危机促进“面向方针编程”的遍及，引入了“方针”概念。而“软件架构”的提出，则标志着“组件”概念的诞生。
这一开展进程提醒了一个中心思维：无论是“模块”、“方针”还是“组件”，其本质都在于对到达必定规划的软件体系进行有用的拆分和高层次安排。跟着软件的杂乱度不断攀升，这种拆分的粒度和层次也随之进步，然后更好地应对软件开发进程中遇到的各种应战，进步软件的开发功率和体系的可保护性。
2.1.2架构指什么
在咱们程序员的国际里，“架构”这个词简直无处不在。它就像是咱们的老朋友，常常挂在嘴边。可是，当你真实停下脚步，试图去探求一下这个问题：“架构”究竟指的是什么？你或许会惊奇地发现，这个问题并没有幻想中那么简略。其实，假如你随意问1000个技能人员，“架构”的界说是什么，你或许会得到1001种不同的答案。这就像是一个技能界的谜题，每个人心中的答案都有奇妙的差异。
那么，在这个议论纷纷的情况下，咱们怎样才干找到对“架构”的准确了解呢？一个有用的办法是先从了解与“架构”严密相关且相似的几对概念开始。咱们可以聚集于三对底子但至关重要的概念：体系与子体系、模块与组件、以及结构与架构。
2.1.2.1体系与子体系
当咱们聊到“体系”，或许首要想到的是各种杂乱的技能或机械设备。维基百科给出了一个十分宽泛但准确的界说：
体系泛指由一群有相关的个别组成，依据某种规矩运作，能完结个别元件不能独自完结的作业的集体。
咱们来简化一下上面的深邃论说，抓住几个中心点：
- 相关：幻想一下，仅仅把一个发动机和一台电脑摆在一同，并不能让它们变成什么特别的东西，对吧？但假如你把发动机、底盘、轮胎和车架这些有相关的部分放在一同，它们就能组合成一台轿车。这便是说，体系里的每个部分都得有点联络，才干一同作业构成一个有用的全体。
- 规矩：在这个组合里，每个部分不是随意干自己的事。它们需求按照必定的规矩来操作。比方说，轿车里的发动机发生动力，经过变速器和传动轴这样的设备，终究把动力传到轮胎上，让轿车可以前进。这些规矩决议了谁担任干什么，怎样协作。
- 才能：当这些部件按规矩合作时，整个别系就能做到单个部件做不到的作业，比方轿车的载人载物。这种体系的才能，不是简略地把各个部件的才能加起来那么简略，而是能创造出新的才能来。
再说说子体系，其实它的概念和体系差不多，只不过是从另一个视点来看。一个别系在更大的环境中，或许便是另一个别系的子体系：
子体系由一群有相关的个别所组成的体系，八成会是更大体系中的一部分。
子体系和体系的概念其实是一回事，仅仅取决于你站在哪个视角看问题。一个别系在更大的环境中就或许成为另一个别系的子体系。这听起来或许有点绕，但假如咱们用微信这个比方来阐明，一切就变得明晰多了。
- 微信作为一个别系：首要，把微信幻想成一个巨大的生态圈，它本身便是一个别系。在这个生态圈里，有许多功用和服务，如聊天、登录、付出、朋友圈等。这些功用在微信这个大体系中，实际上都是独立运转的子体系，每个子体系担任不同的使命，但一起支撑起微信这个巨大的服务平台。
- 朋友圈的结构：再深化到朋友圈，咱们可以看到它不只仅是微信的一个功用，实际上它自己也是一个由多个功用组成的体系。比方，动态发布、谈论、点赞等功用，在朋友圈这个“小体系”里，它们各自也可以被看作是独立的子体系。
- 谈论功用的深层次：谈论功用虽然是朋友圈的一部分，但假如咱们仔细分析，会发现它本身也包含多个子体系，如防刷子体系、审阅子体系、发布子体系、存储子体系等。这些子体系经过精细的协作，一起保证了谈论功用的正常运转和数据的安全性。
- 技能层面的体系：当咱们聚集于谈论审阅这一环节，它或许不再被划分为更多的事务子体系，而是转向技能完成的视角。在这个层面，各种技能模块和组件，如数据库体系MySQL、缓存体系Redis等，它们虽然是从技能视点构成的体系，但同样在整个谈论功用中扮演着要害的人物。这些技能组件保证了数据的快速处理和安全存储，虽然它们不直接参与到事务流程中，却是支撑整个别系运转不可或缺的部分。
这种从全体到部分，再从部分回到全体的视角，不只协助咱们了解了体系内部的杂乱结构，也让咱们了解了在规划和构建杂乱体系时，怎样经过层次分明的子体系来办理和简化这种杂乱性。每个子体系的规划和完成，都需求考虑怎样与其他子体系协作，以及怎样在满意当时功用需求的一起，坚持体系的灵活性和扩展性。
经过微信这个比方，咱们得到的不只仅是对体系和子体系理论的深化了解，还有对实际使用中这些理论怎样被运用以处理实际问题的洞见。这种理论与实践的结合，是软件工程中不可或缺的一部分，它辅导咱们怎样更好地规划和优化软件体系，以习惯不断改动的需求和应战。
2.1.2.2模块与组件
要深化了解软件体系的拆分，咱们可以从两个不同的视角来讨论：逻辑和物理。这就像是看待一个杂乱机器的两种办法。逻辑上的拆分发生了咱们所说的“模块”，而物理上的拆分则给咱们“组件”。
- 模块：把这个概念幻想成是把一本厚厚的教科书分成不同的章节，每一章节专注于讲解一个特定的主题。在软件里，模块便是这样一个逻辑上的单位，它封装了一系列功用，这些功用严密相关，一起完结一项或几项特定的使命。划分模块的意图很明确：为了让咱们的代码愈加有条理，每部分都有明确的职责，这样不只使得代码更易于了解和保护，还能在团队中更高效地协作。
- 组件：再想想组件，可以将其比喻为乐高积木中的每一块积木。这些积木是实实在在的，你可以用它们来构建各式各样的结构。在软件开发中，组件是物理上的实体，可以在不同的体系中重复运用。它们就像是规范化的零件，可以依据需求拼装或更换，极大地进步了开发的灵活性和功率。
提到“组件”的英文“component”，假如咱们将其译为“零件”，或许会愈加形象和易懂。这个词协助咱们更好地掌握组件的本质：它们是独立的、可以交换的物理单位，正如机械中的零件相同，具有了可插拔和可复用的特性。这种物理上的拆分不只让咱们的体系愈加模块化，还为体系的晋级和保护供给了极大的便当。
经过逻辑和物理拆分，咱们可以更精细地办理和构建杂乱的软件体系，使之既有条理又高效。模块化和组件化的规划思维，是现代软件工程中不可或缺的一部分，它们使得软件开发像建立乐高相同既有趣又赋有创造性。
2.1.2.3结构与架构
单纯从界说的视点来看，结构重视的是“规范”，架构重视的是“结构” 。结构（Framework）为你的项目供给了一套预设的东西和库，保证你可以遵循特定的规范和方式来构建使用。幻想一下，假如你正在建立一座房子，结构就像是供给给你的施工套件和详细攻略，它辅导你每一步怎样建造，保证每一部分都能正确地承当起它的作用。架构（Architecture），则更像是整个别系的规划计划，它详细规划了体系的安排办法，展现了组件怎样互相配合，数据怎样流通，以及体系怎样对外供给服务。这相当于在规划整个房子的布局，决议哪里放置客厅，哪里是厨房，以及怎样保证房子既满意居住功用又具有漂亮性。
咱们常常会说，“工程选用的是MVC架构”、“工程运用的是SSH结构”等。这儿，榜首句话是站在结构的层面来阐明，它像是在描绘房子的规划理念和内部结构，告知你这个项目是怎样划分不同的功用区域，以及这些区域是怎样相互相关的。第二句话是站在规范的层面来阐明，它更多重视于建造进程中应该遵循的规范和规矩，比方运用什么样的技能栈，以及怎样运用这些技能来完成预订的功用。
一起，不同的视角会影响咱们对架构的了解和描绘，例如：
- 从事务逻辑的视点分化，“后台办理体系”的架构(图1-3所示)，咱们会重视体系是怎样处理用户的注册、信息办理、事务挑选和数据统计等事务流程的。这个视点让咱们深化了解体系是怎样支撑中心事务需求的。
- 从物理部署的视点分化，“后台办理体系”的架构(如图1-4所示)，则重视体系的硬件布局，怎样经过服务器集群、负载均衡等技能手段来保证体系的高可用性和高功用。
- 从开发结构的视点分化，“后台办理体系”的架构(如图1-5所示)，咱们则愈加重视代码的安排办法、模块的划分以及技能结构的挑选，以便于团队协作、功用迭代和体系保护。
经过不同的视角，咱们不只可以更全面地了解结构和架构的概念，还可以依据项意图实际需求，从多个维度评价和挑选最适宜的架构规划和技能结构。这种多视点的考虑办法关于软件开发是十分重要的，它协助咱们构建出既稳健又灵活的体系，可以习惯不断改动的事务需求和技能应战。
2.1.3架构的界说及鸿沟
谈到“架构是什么”，你或许会发现这个问题没有那么简略。其实，不同的公司、不同的团队，乃至于咱们每个人，关于“软件架构”的了解都各不相同。这就像咱们不能百分之百准确描绘一个杂乱的模型相同，咱们只能从多个视点来看，测验给出一个大概的描绘。所以，想要给出一个完全无懈可击的“架构界说”，那底子是不或许的。
“道可道，十分道。名可名，十分名”。
这个职业内部，充满了各式各样的声响和观点。有的安排或许会从技能的实用性动身，界说架构是一种保证体系稳定、高效运转的布局；有的个人或许更重视架构在处理杂乱问题中的战略人物，视之为一种艺术。每个人都在测验从自己独特的视角，解读和界说“架构是什么”，这就像是在很多的颜色中寻觅那一抹最为适宜的蓝，既充满了个人颜色，也反映了这个范畴的多元和杂乱。
2.1.3.1架构的界说
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
IEEE 关于架构的这个概念：其实，把它幻想成一个三明治，上面是体系的大架构，中间夹着的是各个组件以及它们之间的纽带（这儿的纽带，既包含组件彼此之间的联络，也涵盖了它们与外界环境的互动），底下则是一套举动原则。咱们若是用图形来表达这个界说，那么制造出来的图示应该既清新又直观，可以将架构的首要组成部分和中心思维，一望而知地展现出来(如图1-6所示)：
- 体系的大架构：这部分其实便是在讲，让人一眼就能看懂的体系全体布局。就像是给你一张地图，上面标示了一切重要的地标和路径，让你对整个地势有个底子的认识。
- 组件及其联络：这儿的意思是，把整个别系拆分成一个个模块，这样不只便于了解和办理，一起也强调了这些模块之间，以及模块与外部环境之间的相互作用和联络。就像是一张杂乱的网络图，每个节点都有它的位置和作用，而线则表明了节点之间的衔接。
- 举动原则：这部分供给的是规划和演进体系时需求恪守的规矩和辅导原则。就比方是一本攻略，告知你在寻求方针的进程中，哪些是应该坚持的原则，哪些是需求防止的错误。
大师 Martin Fowler关于架构的界说有着愈加简洁的抽象，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 则像是那位脚踏实地的实践者，他不在云端飘，而是带着东西箱走到了前哨。他从实际操作的视点动身，详细列出了构成软件体系架构的柱石(如图1-7所示)：
- 结构：这不只仅是选一个风格的问题，而是界说了整个使用的骨架，是微服务、是单体，还是服务导向架构（SOA），每一种挑选都像是在向体系注入不同的灵魂。
- 架构特点：这些看不见摸不着的特性，比方功用怎样、可用性凹凸、保护起来是不是友好，它们决议了体系能否在严酷的环境中生存下来。
- 架构决议计划：在规划体系的进程中，那些至关重要的挑选点，就像是在茫茫大海中飞行的舵手，一次又一次地决议着软件的未来方向。
- 规划原则：这些原则就像是老船长的才智，指引着规划者避开暗礁，顺畅抵达意图地。
2.1.3.2结构
结构是体系架构的重要组成部分，其从微观上表述了体系的结构组成。架构规划的中心使命之一是为体系挑选适宜的架构风格。架构师需求依据上下文的权衡，可以挑选模块化单体架构风格，也可以挑选微服务架构风格。
提到架构中的“结构”，这块可不是随意一说就能过去的。它在整个别系架构里边占的位子，就比方心脏在人体里的人物相同重要。它从一个庞大的视角，告知咱们这个别系是由哪些部分组成的，每部分又是怎样协同作业的。搞架构规划的时分，挑选一个适可而止的架构风格，底子上便是架构师的中心日常了。
举个比方，架构师们在面临详细的项目时，得先在大脑中过一遍这个别系的全貌，然后依据这个别系要面临的各种情况和应战，来做一个权衡。这时分，他们或许会挑选走模块化的单体架构风格，这种办法优点是简略、直接，简单办理；但假如项目特别杂乱，服务之间需求高度的解耦，那微服务架构风格或许就更适宜了，虽然这样会带来更多的办理和协调作业，但它能供给更好的灵活性和扩展性。
“挑选适宜的架构风格”的进程(如图 1-8所示)，其实就像是在做一场精心策划的活动，架构师需求凭仗自己的经历和对项目需求的深化了解，做一个详细的规划，希望能赢得未来的便当和功率。这个进程充满了应战，但也正是这些应战，让架构规划成为了一门艺术。
2.1.3.3架构特点
在聊软件架构的时分，绝不能忽视的一个要点便是所谓的架构特点，也便是大家常说的质量特点或非功用特点。这些特点，其实便是在描绘体系应该具有的一些“超才能”，比方能跑得快（高功用）、能灵活扩大或缩小规划（可扩展性和伸缩性）、碰到问题不崩溃（弹性和容错性）、好测好修（可测试性和可保护性）等等。规划架构的时分，咱们的一个中心使命便是要保证体系可以满意这些架构特点的要求，由于它们直接联络到体系能否在野蛮生长的环境中存活下来。
但这儿头有个问题，那便是架构特点多得跟星星相同数不清，咱们有必要了解，在不同的项目和场景下，要点重视哪一部分特点。这就要求架构师得依据详细的问题域和上下文环境，来做出精准的分析和挑选。比方，在一个对功用要求极高的金融交易体系中，高功用和容错性或许便是你得要点重视的特点；而在一个云服务产品中，可扩展性和伸缩性或许更为要害。
一起，架构规划不是一往无前的，这些架构特点(如图 1-9所示)之间很或许存在着某种程度的抵触。例如，寻求极致的功用或许会牺牲必定的可保护性和可测试性。这种时分，架构师就得像是在玩一个平衡游戏，既要保证体系的中心才能，又要尽量防止负面影响，这就需求他们运用自己的经历和才智，做出恰当的权衡和决议计划。
架构规划其实便是一个不断权衡和挑选的进程，旨在打造一个既强壮又平衡的体系。这个进程中，架构师的人物就像是一位艺术家，既要有科学的谨慎性，又要有艺术的创造力。
2.1.3.4架构决议计划
当咱们深化讨论软件架构规划的精华时，架构决议计划这个概念浮现为其间心。它不只仅是关于处理计划的挑选，更是一系列有必要恪守的规矩的表现。这些规矩或决议计划，正如导航灯指引船舶航向，为整个别系规划指明方向。在这个进程中，要认识到并非一切决议计划都能被称为架构决议计划。只有那些对体系有着严重且深远影响的决议计划，才配得上这个称号。比方说，决议选用何种架构风格，这不只会深化影响到体系的全体规划，一旦设定，更改的代价极为贵重，因而，它无疑归于架构决议计划的范畴。
架构决议计划的范围广泛，内容丰厚，它们包含但不限于以下几个要害范畴：
- 直接对架构特点中的优先级高的问题发生影响：这意味着任何影响功用、可扩展性、安全性等要害架构特点的决议计划都是至关重要的。
- 修改对外接口：这类决议计划需求进行周全的影响分析，由于它们或许会对体系与外部国际的交互办法发生底子性的改动。
- 引入或移除依赖：依赖联络的改动标志着体系功用的增减，对架构的影响深远，需求慎重考虑。
- 改动体系的通用结构：这关乎到体系的基础架构布局，任何调整都是对体系架构的严重干涉。
- 促进开发团队改动开发方式：这类决议计划往往触及到开发流程和文明，对团队的作业办法和产品的质量都会发生深远的影响。
- 承当战略性技能债款：有时为了项意图长期开展，需求做出一些短期内看似不利但长远来看有益的技能挑选，这些决议计划对体系的未来开展至关重要。
这些架构决议计划，远不止是技能层面的挑选，它们背面蕴含的是对项目未来方向的深思熟虑。一个正确的架构决议计划可以为项目带来顺畅的开展，而错误的挑选或许导致项目陷入重构乃至失利的困境。因而，在架构规划进程中，架构师需求具有前瞻性和深度的考虑才能，保证每一个决议计划都能促进项目向着正确的方向开展。
2.1.3.5规划原则
规划原则和架构决议计划，这两者在软件规划的国际里，就像是攻略和辅导的联络。两者都指引着你前行的方向，但详细的用法和含义，却大有不同。中心区别在这儿：规划原则，它更像是一位经历丰厚的长辈，给你供给的那些辅导和主张，并不会逼迫你必定要这么做。而架构决议计划，那就相当于规划的规章制度，一旦确认下来，你就有必要得恪守。
举个比方来说得更了解一点，规划原则或许会这样主张你：在软件体系间的通讯上，尽或许运用异步音讯机制。这么做的优点是啥呢？首要，它可以提升体系的功用，让你的使用跑得更快；其次，还能下降体系间的耦合度，让体系之间的联络愈加松散，互不干扰。这就比方是在教你怎样在繁忙的城市中开车，不只能高效地从A点到B点，还能在路上享受风景，防止不必要的麻烦。
但这都是主张，它不会对你说：“你有必要得这么干！”它留给你满足的空间去探求和实验，找到最适合你自己项意图办法。而一旦咱们谈到架构决议计划，比方你决议用微服务架构而非单体架构，这就像是签了一个契约，需求你严格恪守，由于它联络到整个项意图基础和未来的可保护性。
在规划和构建软件体系的时分，了解规划原则与架构决议计划之间的这种奇妙差异，就显得尤为重要。它们一个给你创意和自由，一个给你方向和规矩，正确地运用它们，就能让你的软件规划既灵活又稳健。
2.1.3.6总结
在深化讨论软件架构的界说时，咱们会发现职业内各位大师供给了多样化且各具特色的解读，它们就像是不同风格的画派，每一种都有其独到之处：
- IEEE的界说，就比方是经典主义画派，寻求结构的谨慎和方式的规范，给咱们供给了一个架构界说的规范结构，像是在告知咱们，修建的每一砖每一瓦都要契合修建学的原则。
- Martin Fowler的视点，则像是强调了画作中的构图决议计划，就如同在绘画中挑选主题和颜色的重要性相同，他告知咱们在架构规划中，要害的决议计划是构筑整个别系的柱石。
- Ralph Johnson的界说更像是抽象艺术，他没有给出详细的方式，而是强调了“重要性”这个中心元素，就像是抽象画中强调情感和概念的表达，让咱们了解到架构的中心在于其重要的价值和作用。
- Neil Ford的看法则更接近于现实主义，他经过详细化的描绘，就像是经过细腻的画面描绘出日子的样态，让咱们可以明晰地了解和操作架构的详细元素。
在这些界说中，我个人特别偏爱Ralph Johnson的抽象化界说，它简洁而深化，像是用一笔带过却又点出架构本质。在我的作业实践中，这种将杂乱问题抽象化的才能，成为了我判别和了解架构鸿沟时的重要原则。就像是在画画时，虽然不被详细方式所捆绑，但可以深化掌握著作的灵魂，这样的界说不只辅导了我的架构规划思路，也协助我在面临杂乱体系时，可以愈加聚集于那些真实重要的作业。
2.1.4架构的方针
其实搞架构的底子意图，便是为了处理软件体系那头疼的杂乱度问题。要想搞好架构，中心便是学会怎样做决议计划和挑选。
你面临的是一个有限制的“盒子”，这个盒子代表了你在规划软件时有必要考虑的各种约束条件，比方团队的经历水平、预算本钱、可用资源、时刻限制，以及事务的当时阶段等。这些因素交错在一同，构成了你有必要在其间寻觅最优解的杂乱环境。
在这样的布景下，架构师的使命就变得明晰了：深化分析这个杂乱的“综合体”，了解它对体系架构杂乱度的影响，然后在这个基础上做出合理的判别和挑选。这意味着，你需求评价不同架构计划的优劣，考虑它们怎样习惯或改动现有的约束条件，终究规划出既契合需求又能在给定的条件下发挥最大效能的软件架构。
这个进程并非一成不变，而是需求跟着项目进展、团队才能的成长以及外部环境的改动而不断调整和优化。因而，作为一名架构师，不只需求具有深厚的技能常识和经历，还需求有前瞻性的思维和灵活应变的才能，以保证在不同阶段做出最适合项意图架构决议计划。
